GitHub Actions and Secrets

Notice: December 27, 2020: We only allow Actions that are official "Made by GitHub" or local to the Apache org on GitHub, to address a potential security vulnerability. This is an incident-related policy change. We are researching the situation, and the policy may evolve based on what we learn.

GitHub Actions help you automate your software development workflows in the same place you store code and collaborate on pull requests and issues. You can write individual tasks, called actions, and combine them to create a custom workflow. Workflows are custom automated processes that you can set up in your repository to build, test, package, release, or deploy any code project on GitHub.

A note on testing: Some projects would like to use GitHub Actions for complex processes, such as automating their tests of software builds.

The time runners are in use (measured in minutes) is unlimited for public repositories so how long a test takes isn't the issue. The issue is tying up limited 'runners' (nodes) while those minutes are running. Apache has 180 runners for over 1200 repositories, so the concern would be how many runners the test requires, which are then unavailable to other projects for the duration of the test. Out of those 180 runners, only 50 Mac OS runners can be in use at one time for all ASF projects.

The ASF maxes out its runner allocation quite often, so a project needs to plan carefully to make best use of them for everyone's sake. For example, it would be important not to trigger a full release test with a pull request that is correcting a typo on one page in one module.

Evolving knowledge

• If you are considering using GitHub Actions with buildsy, please subscribe to the builds@ a.o mailing list, where there is a continuing discussion on this topic and others related to continuous integration development.

• The community is curating a Wiki page about the current state of using GitHub Actions for ASF projects.

• See Apache Airflow's experience with Actions.

GitHub Secrets are encrypted environment variables that you create in a repository or organization. The secrets you create are available to use in GitHub Actions workflows.

A GitHub Token is a string of characters that functions similarly to an OAuth token in that you can specify its permissions via scopes. A personal access token is also similar to a password, but you can have many of them and you can revoke access to each one at any time. As an example, you can enable a personal access token to write to your repositories. If then you run a cURL command or write a script that creates an issue in your repository, you would pass the personal access token to authenticate. You can store the personal access token as an environment variable to avoid typing it every time you use it.

See GitHub secrets and tokens.

Examples

GitHub Secrets

Apache Arrow has GitHub Secrets added to their Arrow GitHub repos with the name 'DOCKERHUB_USER' and token 'DOCKERHUB_TOKEN' created as the user account on DockerHub (those account details are in LP). Additionally, in DockerHub, an 'arrow-dev' repository was created and the DockerHub 'jenkins' team (containing the DockerHub 'DOCKERHUB_USER' user) was given admin access.

GitHub Actions

Using Apache Arrow again as an example, the tokens above can be called using this code:

run: |
docker login -u ${{ secrets.DOCKERHUB_USER }} \
-p ${{ secrets.DOCKERHUB_TOKEN }}
docker-compose push ...