Reputation: 7848
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?
Upvotes: 9
Views: 6918
Reputation: 12293
I do the following, which is simple and effective:
.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.
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:
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).env
file itemsSource: I created/run Chipper CI, a CI platform for Laravel.
Upvotes: 1
Reputation: 7848
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.
You keep your .env
file in the repository. Use dotenv actions to read your file into the workflow.
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 :)
Upvotes: 2
Reputation: 1620
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.
Upvotes: 2