updated the README information

Author: Jibola

CONTRIBUTING.md

@@ -46,7 +46,7 @@ That will also contain all the generated files with the generated variables, but
 
 * `./scripts/discard-dev-files.sh`:
 
-After using `./scripts/dev-fsfp-back.sh`, there will be a bunch of generated files with the variables for the generated project that you don't want to commit, like `README.md` and `.gitlab-ci.yml`.
+After using `./scripts/dev-fsfp-back.sh`, there will be a bunch of generated files with the variables for the generated project that you don't want to commit, like `README.md` and `.actions.yml`.
 
 To discard all those changes at once, run `discard-dev-files.sh` from the root of the project, e.g.:
 

docs/development-guide.md

@@ -68,8 +68,8 @@ The input variables, with their default values (some auto generated) are:
 - `traefik_public_constraint_tag`: The tag that should be used by stack services that should communicate with the public.
 - `flower_auth`: Basic HTTP authentication for flower, in the form`user:password`. By default: "`admin:changethis`".
 - `sentry_dsn`: Key URL (DSN) of Sentry, for live error reporting. You can use the open source version or a free account. E.g.: `https://1234abcd:[email protected]/30`.
-- `docker_image_prefix`: Prefix to use for Docker image names. If you are using GitLab Docker registry it would be based on your code repository. E.g.: `git.example.com/development-team/my-awesome-project/`.
-- `docker_image_backend`: Docker image name for the backend. By default, it will be based on your Docker image prefix, e.g.: `git.example.com/development-team/my-awesome-project/backend`. And depending on your environment, a different tag will be appended ( `prod`, `stag`, `branch` ). So, the final image names used will be like: `git.example.com/development-team/my-awesome-project/backend:prod`.
+- `docker_image_prefix`: Prefix to use for Docker image names. If you are using A non-DockerHub registry it would be based on your code repository. E.g.: `quay.io/development-team/my-awesome-project/`.
+- `docker_image_backend`: Docker image name for the backend. By default, it will be based on your Docker image prefix, e.g.: `quay.io/development-team/my-awesome-project/backend`. And depending on your environment, a different tag will be appended ( `prod`, `stag`, `branch` ). So, the final image names used will be like: `quay.io/development-team/my-awesome-project/backend:prod`.
 - `docker_image_celeryworker`: Docker image for the celery worker. By default, based on your Docker image prefix.
 - `docker_image_frontend`: Docker image for the frontend. By default, based on your Docker image prefix.
 

docs/getting-started.md

@@ -39,7 +39,7 @@ This FastAPI, React, MongoDB repo will generate a complete web application stack
 - **Flower** for Celery jobs monitoring.
 - Load balancing between frontend and backend with **Traefik**, so you can have both under the same domain, separated by path, but served by different containers.
 - Traefik integration, including Let's Encrypt **HTTPS** certificates automatic generation.
-- GitLab **CI** (continuous integration), including frontend and backend testing.
+- **Github Actions** (continuous integration), including backend testing.
 
 
 

scripts/dev-fsfp-back.sh

@@ -19,4 +19,4 @@ rm -rf ./full-stack-fastapi-mongodb/\{\{cookiecutter.project_slug\}\}/*
 
 rsync -a --exclude=node_modules ./dev-fsfp/* ./full-stack-fastapi-mongodb/\{\{cookiecutter.project_slug\}\}/
 
-rsync -a ./dev-fsfp/{.env,.gitignore,.gitlab-ci.yml} ./full-stack-fastapi-mongodb/\{\{cookiecutter.project_slug\}\}/
+rsync -a ./dev-fsfp/{.env,.gitignore,.github/workflows/actions.yml} ./full-stack-fastapi-mongodb/\{\{cookiecutter.project_slug\}\}/

scripts/discard-dev-files.sh

@@ -7,7 +7,7 @@ rm -rf \{\{cookiecutter.project_slug\}\}/backend/app/poetry.lock
 rm -rf \{\{cookiecutter.project_slug\}\}/frontend/node_modules
 rm -rf \{\{cookiecutter.project_slug\}\}/frontend/.nuxt
 git checkout \{\{cookiecutter.project_slug\}\}/README.md
-git checkout \{\{cookiecutter.project_slug\}\}/.gitlab-ci.yml
+git checkout \{\{cookiecutter.project_slug\}\}/.github/workflows/actions.yml
 git checkout \{\{cookiecutter.project_slug\}\}/cookiecutter-config-file.yml
 git checkout \{\{cookiecutter.project_slug\}\}/.env
 git checkout \{\{cookiecutter.project_slug\}\}/frontend/.env

{{cookiecutter.project_slug}}/.gitlab-ci.yml

@@ -134,7 +134,7 @@ The file `./scripts/test.sh` has the commands to generate a testing `docker-stac
 
 The tests run with Pytest, modify and add tests to `./backend/app/app/tests/`.
 
-If you use GitLab CI the tests will run automatically.
+If you use Github Actions the tests will run automatically.
 
 #### Local tests
 
@@ -387,7 +387,7 @@ Done, you have a frontend-less (api-only) app. 🔥 🚀
 If you want, you can also remove the `FRONTEND` environment variables from:
 
 * `.env`
-* `.gitlab-ci.yml`
+* `.github/workflows/actions.yml`
 * `./scripts/*.sh`
 
 But it would be only to clean them up, leaving them won't really have any effect either way.
@@ -622,16 +622,18 @@ docker stack deploy -c docker-stack.yml --with-registry-auth "${STACK_NAME?Varia
 
 ### Continuous Integration / Continuous Delivery
 
-If you use GitLab CI, the included `.gitlab-ci.yml` can automatically deploy it. You may need to update it according to your GitLab configurations.
+In order to run properly in Github, you need to provide a `secrets.DOCKERHUB_USERNAME` and `secrets.DOCKERHUB_PASSWORD` in your Github repository secrets. Read more [here](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions) on how that is done.
 
-If you use any other CI / CD provider, you can base your deployment from that `.gitlab-ci.yml` file, as all the actual script steps are performed in `bash` scripts that you can easily re-use.
+If you use Github Actions, the included `actions.yml` can automatically deploy it. You may need to update it according to your Github configurations. Please check the `actions.yml` file for details on deployment steps
 
-GitLab CI is configured assuming 2 environments following GitLab flow:
+If you use any other CI / CD provider, you can base your deployment from that `actions.yml` file, as all the actual script steps are performed in `bash` scripts that you can easily re-use.
+
+Github Actions is configured assuming 2 environments following Github flow:
 
 * `prod` (production) from the `production` branch.
 * `stag` (staging) from the `master` branch.
 
-If you need to add more environments, for example, you could imagine using a client-approved `preprod` branch, you can just copy the configurations in `.gitlab-ci.yml` for `stag` and rename the corresponding variables. The Docker Compose file and environment variables are configured to support as many environments as you need, so that you only need to modify `.gitlab-ci.yml` (or whichever CI system configuration you are using).
+If you need to add more environments, for example, you could imagine using a client-approved `preprod` branch, you can just copy the configurations in `actions.yml` for `stag` and rename the corresponding variables. The Docker Compose file and environment variables are configured to support as many environments as you need, so that you only need to modify `actions.yml` (or whichever CI system configuration you are using).
 
 ## Docker Compose files and env vars
 

{{cookiecutter.project_slug}}/README.md

@@ -143,7 +143,7 @@ The file `./scripts/test.sh` has the commands to generate a testing `docker-stac
 
 The tests run with Pytest, modify and add tests to `./backend/app/app/tests/`.
 
-If you use GitLab CI the tests will run automatically.
+If you use Github Actions the tests will run automatically.
 
 #### Local tests
 
@@ -396,7 +396,7 @@ Done, you have a frontend-less (api-only) app. 🔥 🚀
 If you want, you can also remove the `FRONTEND` environment variables from:
 
 * `.env`
-* `.gitlab-ci.yml`
+* `.github/workflows/actions.yml`
 * `./scripts/*.sh`
 
 But it would be only to clean them up, leaving them won't really have any effect either way.
@@ -631,16 +631,18 @@ docker stack deploy -c docker-stack.yml --with-registry-auth "${STACK_NAME?Varia
 
 ### Continuous Integration / Continuous Delivery
 
-If you use GitLab CI, the included `.gitlab-ci.yml` can automatically deploy it. You may need to update it according to your GitLab configurations.
+In order to run properly in Github, you need to provide a `secrets.DOCKERHUB_USERNAME` and `secrets.DOCKERHUB_PASSWORD` in your Github repository secrets. Read more [here](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions) on how that is done.
 
-If you use any other CI / CD provider, you can base your deployment from that `.gitlab-ci.yml` file, as all the actual script steps are performed in `bash` scripts that you can easily re-use.
+If you use Github Actions, the included `actions.yml` can automatically deploy it. You may need to update it according to your Github configurations. Please check the `actions.yml` file for details on deployment steps
 
-GitLab CI is configured assuming 2 environments following GitLab flow:
+If you use any other CI / CD provider, you can base your deployment from that `actions.yml` file, as all the actual script steps are performed in `bash` scripts that you can easily re-use.
+
+Github Actions is configured assuming 2 environments following Github flow:
 
 * `prod` (production) from the `production` branch.
 * `stag` (staging) from the `master` branch.
 
-If you need to add more environments, for example, you could imagine using a client-approved `preprod` branch, you can just copy the configurations in `.gitlab-ci.yml` for `stag` and rename the corresponding variables. The Docker Compose file and environment variables are configured to support as many environments as you need, so that you only need to modify `.gitlab-ci.yml` (or whichever CI system configuration you are using).
+If you need to add more environments, for example, you could imagine using a client-approved `preprod` branch, you can just copy the configurations in `actions.yml` for `stag` and rename the corresponding variables. The Docker Compose file and environment variables are configured to support as many environments as you need, so that you only need to modify `actions.yml` (or whichever CI system configuration you are using).
 
 ## Docker Compose files and env vars
 

{{cookiecutter.project_slug}}/backend/app/README.md

@@ -44,7 +44,7 @@ This project is a comprehensively updated React + MongoDB version of [Sebastián
 - **Flower** for Celery jobs monitoring.
 - Load balancing between frontend and backend with **Traefik**, so you can have both under the same domain, separated by path, but served by different containers.
 - Traefik integration, including Let's Encrypt **HTTPS** certificates automatic generation.
-- GitLab **CI** (continuous integration), including frontend and backend testing.
+- **Github Actions** (continuous integration), including backend testing.
 
 ## How to use it
 
@@ -103,8 +103,8 @@ The input variables, with their default values (some auto generated) are:
 
 - `sentry_dsn`: Key URL (DSN) of Sentry, for live error reporting. You can use the open source version or a free account. E.g.: `https://1234abcd:[email protected]/30`.
 
-- `docker_image_prefix`: Prefix to use for Docker image names. If you are using GitLab Docker registry it would be based on your code repository. E.g.: `git.example.com/development-team/my-awesome-project/`.
-- `docker_image_backend`: Docker image name for the backend. By default, it will be based on your Docker image prefix, e.g.: `git.example.com/development-team/my-awesome-project/backend`. And depending on your environment, a different tag will be appended ( `prod`, `stag`, `branch` ). So, the final image names used will be like: `git.example.com/development-team/my-awesome-project/backend:prod`.
+- `docker_image_prefix`: Prefix to use for Docker image names. If you are using non-native Docker registry it would be based on your code repository. E.g.: `quay.io/development-team/my-awesome-project/`.
+- `docker_image_backend`: Docker image name for the backend. By default, it will be based on your Docker image prefix, e.g.: `quay.io/development-team/my-awesome-project/backend`. And depending on your environment, a different tag will be appended ( `prod`, `stag`, `branch` ). So, the final image names used will be like: `git.example.com/development-team/my-awesome-project/backend:prod`.
 - `docker_image_celeryworker`: Docker image for the celery worker. By default, based on your Docker image prefix.
 - `docker_image_frontend`: Docker image for the frontend. By default, based on your Docker image prefix.