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.