Understanding .env. docker compose and Github Actions

[inrsta]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched in the documentation/README.
• I already searched in Google "How to do X" and didn't find any information.
• I already read and followed all the tutorial in the docs/README and didn't find an answer.

Commit to Help

• I commit to help with one of those options 👆

Example Code

name: Test Docker Compose

on:
  push:
    branches:
      - master
  pull_request:
    types:
      - opened
      - synchronize

jobs:

  test-docker-compose:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - run: docker compose build
      - run: docker compose down -v --remove-orphans
      - run: docker compose up -d --wait
      - name: Test backend is up
        run: curl http://localhost:8000/api/v1/utils/health-check
      - name: Test frontend is up
        run: curl http://localhost:5173
      - run: docker compose down -v --remove-orphans

Description

I am having trouble understanding how to deal with Github Actions and the docker-compose files. I am opening this discussion with the hope that somebody will provide more information about how this repo is meant to be used.

I see that the test-docker-compose.yml Github Action will run the command docker compose build which depends on the .env file existing in the repo. I also believe that committing .env files is not best practice since it contains information you don't want to necessarily have online. I am finding it difficult to understand what the best way to solve this is.

Currently I am not yet ready to have a domain so I am focused only on local developing. I would be very interested to know how you guys manage the Github Actions on your personal projects which are based on this repo. I would also like to know if there is a Discord Server where such discussions can take place.

Operating System

macOS

Operating System Details

15.0.1 (24A348)

Python Version

Python 3.12.5

Additional Context

No response

[gdoda]

Normally the .env shouldn't be posted in public repositories, but given the context of this project the .env has been made available in the repository. The .env in this case does not have any critical and strictly private keys. Since the .env is in the repository, when the workflow runs, the first step is to clone the repository into the workflow's workspace. After the checkout step then the entire repository is available for the subsequent steps. This means that the workflow's workspace has the .env available, making it succeed.

If you want to use it in private repositories, I think you have to setup GitHub Actions Secrets and update the workflow to use your repository secrets.

[tylermilner]

I recently started using this template and came across this use case myself. Even though my repository is private (for the time being), I still didn't like the idea that the .env file was committed to and available in source control.

I tried a couple of approaches to solving this, which I'll outline below.

Approach 1 - Utilize GitHub Actions Secrets

As @gdoda mentioned above, setting up the corresponding GitHub Actions secrets for your repository could be one way to get the workflows running without a main .env file available. First, you will need to add the secrets to the Settings --> Secrets and variables --> Actions page of your repository:

After adding the secrets in the GitHub settings UI, you also need to make those secrets available to the job or steps in the job using the {{ secrets.VARIABLE_NAME }} syntax. For example, the workflow in the original post might end up looking something like this:

jobs:

  test-docker-compose:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - run: docker compose build
      - run: docker compose down -v --remove-orphans
      - run: docker compose up -d --wait
+       env:
+         SECRET_KEY: ${{ secrets.SECRET_KEY }}
+         FIRST_SUPERUSER: ${{ secrets.FIRST_SUPERUSER }}
+         FIRST_SUPERUSER_PASSWORD: ${{ secrets.FIRST_SUPERUSER_PASSWORD }}
      - name: Test backend is up
        run: curl http://localhost:8000/api/v1/utils/health-check
      - name: Test frontend is up
        run: curl http://localhost:5173
      - run: docker compose down -v --remove-orphans

Personally, I found the process of manually adding all of the necessary secrets/environment variables to both the GitHub UI and workflow yml files a bit tedious. This stack overflow post has some good information on alternatives that are worth considering.

Approach 2 - Utilize Default .env File

Instead of going that route, I decided to deviate from the .env setup for this template and added .env to my .gitignore to avoid committing it to source control (which I did before ever committing the .env file). If you have already committed the .env file, then you can still start ignoring the .env file, but you should consider all of the secrets compromised and you should generate new values for all of your secrets).

Once the .env file was added to .gitignore so that it's ignored by source control, I duplicated it into a .env.example and changed all of the values back to the defaults (e.g. simple values like "changethis" for secrets/passwords). Then, I committed the .env.example and updated my documentation/getting started guide to make it clear that first-time devs should copy .env.example to .env and update the values to start developing locally.

Now that I had a basic .env.example in the repo, I made that setup step to copy .env --> .env.example part of my GitHub Actions workflow yml. The updated workflow now looks something like this:

jobs:

  test-docker-compose:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
+     - run: cp .env.example .env
      - run: docker compose build
      - run: docker compose down -v --remove-orphans
      - run: docker compose up -d --wait
      - name: Test backend is up
        run: curl http://localhost:8000/api/v1/utils/health-check
      - name: Test frontend is up
        run: curl http://localhost:5173
      - run: docker compose down -v --remove-orphans

In my opinion, this is the much simpler option since you don't need to setup GitHub Actions secrets for all of the variables and update all of your yml workflows to make those secrets available to each job/step. As a bonus, you now have a default .env.example file that other devs can use to quickly get started with the project and you are no longer storing the main .env file in the repo (which I agree is a best practice in general).