Some environment variables are set up automatically by GitHub (in the runner). We can use these variables in our workflows by referencing them with $VARIABLE_NAME.
Some of them are:
- $GITHUB_SHA will return the SHA of the commit that triggered the workflow
- $GITHUB_REPOSITORY will return the user_name/repo_name in which the workflow is running
- $GITHUB_WORKSPACE will return the workspace directory in the runner.
You can see the complete list of built-in environment variables here.
We can define our own environment variables as well. To declare a variable we need to use the env key at the start of our workflow. This key takes as its value a list of key:value pairs, where the keys are the names of the environment variables that we are declaring, and its values are the values of the variables.
After that we can just write our jobs as we would normally do. To access the variables we just need to use the ${ VAR_NAME } syntax.
Variables declared this way will be available to the whole workflow. Variables that need to only be available to a specific job in the workflow are declared and used in the same way, but using the env in that specific job.
Likewise, if we want a variable to only be available in a step of a job, we use declare and use it in that step.
Some variables need to be encrypted. To do so, we just need to add the variable value in Settings > Secrets > Actions > New repository secret. Give it a name and a value, and save it. These variables will be available in a workflow using an object called secrets.
One secret that is automatically available on workflows is secrets.GITHUB_TOKEN. This token can be used to access the GitHub API, or to push something to the repo, etc. Basically, any time that the action needs to interact with the repository it will need authentication, and we can use this variable to do it.
Secrets can be safely logged because GitHub will never expose them to the logs. It will print them as asterisks.
The authentication token can also be accessed via the github object. This object is automatically set for us by GitHub and contains several other values too. More on that object latter.
Secrets are useful but they have a limit of 6kbs. Likewise, we might be using some CLI commands in a workflow that uses some secrets that need to be stored in a JSON file. We can push encrypted versions of those files and then include a decryption step in our jobs.
To encrypt the file locally we can use tools like GPG. For details on how to use this tool, refer to the encrypted secrets documentation here. Since this files require a passphrase to be decrypted, that passphrase needs to be added as a repository secret. And since the encrypted file itself needs to be available in the runner, workflows that require them must first include a checkout step.
