.env files in Github Actions CI/CD workflows: how to provide these into the workflow

Question

I use Github Actions workflows for my CI/CD processes for Node and PHP projects.

Within a workflow I clone my repository into Github Actions runner virtual machine. Then in order to run tests within a workflow I have to have the .env file in the cloned repository.

The problem is my .env file is not a part of repository (which is the ubuquitous practice).

To solve the problem I use what I consider a workaround: set up MY_PROJECT_ENV Github Action sercret variable, manually put there the content of my .env file and then dynamically create the .env file within my workflow with Linux console echo "${{ secrets.MY_PROJECT_ENV}}" > .env. This works.

But I would like to know are there other approaches for providing .env files to Github Actions workflows?

Answer 1

As you know .env doesn't mean to push to the remote repository.

You need to somehow add the environment variables to the machine that you're running the program.

In your case, you can add environment variables by using the .yaml file as below

steps:
  - name: Hello Program
    run: Hello $FIRST_NAME $LAST_NAME!
    env:
      FIRST_NAME: Akhil
      LAST_NAME: Pentamsetti

for more information please visit github official doc about using the environment variables.

Answer 2

There are 3 ways to do this I know by now. I put the answer to my own question a year after in the different question. See there.

For the sake of SO rules and findablity I put here a summary.

1. You keep your .env file in the repository. Use dotenv actions to read your file into the workflow.

2. You keep the file out of the repository. Then you have 2 ways of getting .env variables:

   2.1. as I wrote in my question above manually copy the file content to the GitHub actions secret variable and then in your workflow create the .env file from that variable.

   2.2. Use the GitHub Actions API to create/update the secrets: write the NodeJS script on your machine (chances are you anyway use Webpack, Gulp or the like Node thing so you have Node installed).

   The script should read the local .env files and write their content to the GH secrets. Of course you can write a custom console utilty to do this with any language you use in your project.

As easy as this :)

Answer 3

I do the following, which is simple and effective:

1. Add environment variables (either define them in the yaml file or as secrets) as needed
2. Keep .env.example in the repository, and run the following at the start of the CI job:

# Create the .env file
cp .env.example .env

# Install dependencies so we can run artisan commands
composer install ...

# generate an APP_KEY
php artisan key:generate

An alternative to this is to commit a .env.ci file to the repository with env vars specific to the CI environment, and run cp .env.ci .env when running tests. Sensitive keys should still be set as secrets.

You can technically provide all of your env vars between secrets / env's in the YAML file and have no .env file, but I like having a random APP_KEY set per test run to ensure there's nothing relying on a specific APP_KEY.

Environment Precedence

As an aside, here's how environment precedence works with Laravel in phpunit tests. This is laravel specific and may come at a surprise as it's not exactly how phpunit alone works outside of Laravel:

1. Env vars set in phpunit.xml always "win" (this is true in Laravel despite what phpunit's docs say about system env vars taking precedence over phpunit.xml file items)
2. System environment variations (in GitHub actions, these are ones set as an env var when running commands in the yaml file)
3. .env file items

Source: I created/run Chipper CI, a CI platform for Laravel.