Move CI to GitHub Actions

[rajadain]

No description provided.

[rajadain]

Check the Azavea Project Template for the latest GitHub Actions Workflow

[rajadain]

Based on GitHub Actions experiments in #3586, now investigating having a self-hosted runner instead.

One thing to note is that the runners operate at the repository, organization, or enterprise level:

You can add self-hosted runners at various levels in the management hierarchy:

• Repository-level runners are dedicated to a single repository.
• Organization-level runners can process jobs for multiple repositories in an organization.
• Enterprise-level runners can be assigned to multiple organizations in an enterprise account.

This means that the self-hosted runner will have to be either specific to this repo or to the WikiWatershed organization. That may mean that it won't work for other projects within the Azavea organization.

It is unclear if a single physical server can support more than one organization's runner. Will update here when I find that out.

[rajadain]

The self-hosted runner does not need to be accessible from the internet, as long as it can access the internet itself, since the GitHub Actions Runner application long-polls GitHub for jobs:

Since the self-hosted runner opens a connection to GitHub.com, you do not need to allow GitHub to make inbound connections to your self-hosted runner.

[rajadain]

This could be problematic: GitHub recommends we use self-hosted runners with only private repos, because forks of public repos would run the same jobs. Wonder if we could do some sort of URL check before executing jobs to only allow the canonical repo?

We recommend that you only use self-hosted runners with private repositories. This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

I'm now going through their security recommendations for self-hosted runners.

[rajadain]

May have to add a CODEOWNERS file too, especially to protect any changes that could be made to the workflows file.

[rajadain]

🤔

Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow.

As a result, self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private or internal repositories, as anyone who can fork the repository and open a pull request (generally those with read access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the GITHUB_TOKEN which, depending on its settings, can grant write access to the repository. Although workflows can control access to environment secrets by using environments and required reviews, these workflows are not run in an isolated environment and are still susceptible to the same risks when run on a self-hosted runner.

[rajadain]

Some more details on workflows from forks:

Workflows don't run in forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository.

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. The GITHUB_TOKEN has read-only permissions in pull requests from forked repositories. For more information, see "Authenticating with the GITHUB_TOKEN."

Also, workflows from pull requests from forks may not run automatically, and may need explicit approval.