Switch CI System to GitHub Actions?

[salvis2]

On the last cloud deployment call, we were thinking of switching the CI system from CircleCI to GitHub Actions. Some of the perks of that are:

• I think most people are more familiar with GitHub Actions over CircleCI
• GitHub is already where we host the code, so it's more convenient
• GitHub Actions can pull hubploy as a Docker image
• Can just keep secrets in GitHub, don't have to keep them in CircleCI

There was also some talk between @jhamman and myself about augmenting this with a new GitHub Action to do deployment statuses as a part of the CI system. This could replace the staging -> prod workflow. @jhamman had an example on a CarbonPlan repo. Here is the GitHub Action that performs a similar function, but with Vercel instead of the new Action.

ping @TomAugspurger @scottyhq @rabernat, would love to hear your thoughts on this!

I've used hubploy in this manner for both hackweeks that I set up infrastructure for. It would require us to bundle everything under hubploy or set up more Actions for interactions with other namespaces, but the Action looks a lot nicer: here is the Action from OceanHackWeek's Hub.

[TomAugspurger]

No objections here.

[scottyhq]

this would be awesome! let's do it

[salvis2]

I think to start, I'll just setup an Action for the AWS hub's staging branch. If that seems to work I can expand to other hubs. Pieces of CI:

• Install dependencies (will just be hubploy)?
• Unlock default secrets
• Unlock OOI secrets
• Build AWS image
• Build GCP image
• Build OOI image
• Setup Helm
• Handle dynamic IP handling for AWS hub
• Deploy AWS hub
• Deploy GCP hub
• Deploy OOI hub

I'll update this list as I remember what CI steps are encapsulated in hubploy and what we will need to manually work on.

I can also hold off on this if we want to have some other work done first, just let me know @TomAugspurger .

[salvis2]

Updates: from conversation with @tjcrone - #759 (comment) - I think it would be a good idea to separate the CI actions by build / deploy and AWS / GCP / OOI. If we only update the AWS hub's config, we shouldn't need to re-deploy GCP and OOI. This is reflected in work for #754 , which is only going to affect the AWS hub's staging cluster for now.

[salvis2]

So PRs #754 and #774 have set up a GitHub Action for building the AWS hub's Docker image and deploying the AWS hub. These are currently active on staging but not prod. Actions are working!

Since the actions are separate workflow files, there's increased readability, the actions can run in parallel, and we can specify a version of hubploy that doesn't affect other workflows. Also, with more specific paths set for each action, there should be less code run for any given commit / PR, making the actions faster.

We will probably enable workflow triggering for prod after this seems to prove itself on staging, but I will leave the other hubs be.

[salvis2]

This PR got closed by pangeo-bot, but the comment here illustrates a problem: #781 (comment). We can't actually build and push in a PR because we can't access repository secrets in a fork, where the PR action is run.

I think I have a fix: we don't need to push the image if the PR doesn't get merged, so I can remove the --push flag from the build command. The PR check should just test that the image can build. Pushing should wait until the PR is merged and the proper branch is actually updated. I'll need to break the build action into two pieces, but that's fine.

If that doesn't work, we can put the image test building piece back into CircleCI, where it always has access to the secrets.

[TomAugspurger]

I didn't look too closely, but you can access secrets from a pull_request_target build. That's used in https://github.com/pangeo-data/pangeo-binder/blob/staging/.github/workflows/test-staging.yml.

The potential problem that the version of the workflow on master is used.

But I agree that not pushing till merge is probably the right move anyway.