Github Actions in more details

Github Actions is live now! Thus, it is the perfect time to go further with the review (see the first article) to add some more details. We will now cover some of Github Actions’ crucial functionality. This will include the following topics:

• Environmental variables
• Github Actions Secrets
• Action marketplace and 3rd party actions

Environmental variables

If you have ever worked with scripts and CI/CD tools you probably noticed (if not yet you will soon) that Environmental Variables play an essential role. Environmental Variables are of course supported by GitHub Actions as well. First of all, it is worth mentioning that there is a list of predefined environment variables which are really useful. Here is the table describing them:

• HOME: The path to the GitHub home directory used to store user data. For example, /github/home.
• GITHUB_WORKFLOW: The name of the workflow.
• GITHUB_ACTION: The unique identifier (id) of the action.
• GITHUB_ACTIONS: Always set to true when GitHub Actions is running the workflow. You can use this variable to differentiate when tests are being run locally or by GitHub Actions.
• GITHUB_ACTOR: The name of the person or app that initiated the workflow. For example, octocat.
• GITHUB_REPOSITORY: The owner and repository name. For example, octocat/Hello-World.
• GITHUB_EVENT_NAME: The name of the webhook event that triggered the workflow.
• GITHUB_EVENT_PATH: The path of the file with the complete webhook event payload. For example, /github/workflow/event.json.
• GITHUB_WORKSPACE: The GitHub workspace directory path. The workspace directory contains a subdirectory with a copy of your repository if your workflow uses the actions/checkout action. If you don’t use the actions/checkout action, the directory will be empty. For example, /home/runner/work/my-repo-name/my-repo-name.
• GITHUB_SHA: The commit SHA that triggered the workflow. For example, ffac537e6cbbf934b08745a378932722df287a53.
• GITHUB_REF: The branch or tag ref that triggered the workflow. For example, refs/heads/feature-branch-1. If neither a branch or tag is available for the event type, the variable will not exist.
• GITHUB_HEAD_REF: Only set for forked repositories. The branch of the head repository.
• GITHUB_BASE_REF: Only set for forked repositories. The branch of the base repository.

Here is an example of the use of predefined environment variables:

name: Docker Image CI

on: 
  push:
jobs:
  build:
     runs-on: ubuntu-latest
    steps:
      run: |
        echo $GITHUB_WORKFLOW
        echo $GITHUB_REF

Naturally, this workflow will print its name and the branch that triggered the workflow, here is the sample output: Sample CI refs/heads/master You are allowed to declare your own environmental variables and use them. It is possible to declare variables on every section such as on step, job or workflow. However, the variables will be visible only within that section. The variables with the name prefix “GITHUB_” are reserved and can not be used. The way of accessing and re-setting variables is specific to the OS on which you run your workflow. Here is how you can declare your own environmental variables:

on: 
  push:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Test Var
      env:
        VAR: "Hello_From_Var"
      run: |
        echo $VAR

This variable will be visible within the “Test Var” section only.

Github Actions Secrets

You will face an issue with how to store passwords and keys while automating any process. Obviously it is not the best decision to keep them in the source code in repos and you do not want it to be visible on the console while executing your workflow. In this regard, Github Actions used secrets to store and use sensitive data without explicitly putting them in source or YAML. You can add project specific secrets in the following way:  Project page⇒ Settings⇒ Secrets Check out also the screenshot below. After secret is registered in project secrets you can use them rom your workflow in the following way:

on: 
  push:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Identify environment
      env:
        pass: ${{ secrets.DOCKER_PASS }}
        username: ${{ secrets.DOCKER_USERNAME }}
      run: |
        docker login hub.docker.com -u$username -p$pass      

This workflow will log in into your docker hub account without showing up the password. However, if you need to store your GitHub Token in secrets you do not have to bother yourself because there is a predefined secret called “secrets.GITHUB_TOKEN” which is your personal access token. Here is the list of permissions for …

Permission	Access type	Access by forked repos
checks	read/write	read
contents	read/write	read
deployments	read/write	read
issues	read/write	read
metadata	read	read
packages	read/write	read
pull requests	read/write	read
repository projects	read/write	read
statuses	read/write	read

If you need a token that requires permissions that aren’t available in the GITHUB_TOKEN, you can create a personal access token and set it as a secret in your repository.

Action Marketplace

Github Action Marketplace suggests various types of developed actions for some standard use cases. The best example of such a use case is code checkout. We will need to access source code from repository pretty often, however you do not have to type git commands every time. Instead,  you may use action called “checkout”. Here is an example of how to use checkout action.

on: 
  push:    
jobs:
  build:
       runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Build
      run: |
        dotnet build

In this workflow we are calling action from the marketplace by using “uses” keyword. It is possible to define the version of the action (v1 in this specific example). This is one example, however there are thousands of other actions used for various purposes, here are 3 of my favorite actions:

• FTP Deploy – used to copy files to FTP server
• Azure login – used to log in to Azure cloud and deploy apps later
• Bump Versions – used to automatically bump version in GitHub Releases

Conclusion

As a conclusion we can state that GitHub Actions provides a pretty convenient toolstack in terms of environmental variables and secrets. It is worth highlighting the possibility to declare and use variables in every section (or subsection) of a workflow and use or access them only within that section. What concerns secrets they provide a pretty standard and known solution. However, while using secrets you will feel that it would have been great to have a concept of “global” secrets which are persistent on all projects (e.g. docker registry login and pass). This would allow us to avoid repetition of secrets for every project. Overall the system looks nice and we will continue to review its functionality in future. We plan to review billing and pricing (as soon as it is live) and go deeper with YAML file structure and also to “play” with more complicated workflows.