GCP function deployment via workflows

[falquaddoomi]

Closes #5

This PR adds one workflow per function (i.e., one for convert-ids and one for ml) that redeploys the function whenever anything is merged into main that alters the function's code.

The PR includes a helper workflow, helper-deploy-func.yaml, which does the following:

1. installs the gcloud tools
2. authenticates to GCP as the cloud-function-deployer service account, via a service account credentials file stored as a secret in this repo
3. pulls the data archive associated with the current function from a GCS bucket, unless it's already in the GitHub actions cached
4. extracts the data archive, caches the resulting data under a hash of the data archive
5. deploys the function

Each function mentioned above uses the function deployer helper workflow to minimize code duplication.

[netlify]

✅ Deploy Preview for gene-plexus canceled.

Name	Link
🔨 Latest commit	4c3137d
🔍 Latest deploy log	https://app.netlify.com/sites/gene-plexus/deploys/66293beecb0e4b0008ce3410

[vincerubinetti]

I'll try forking this and testing it, short of actually providing the secrets and deploying to GCP.

[vincerubinetti]

Well, couldn't test much with a fake GCP key, but it seems to look as expected.

Suggestion: I've been adding this to all my workflows now because it's very handy. If a job fails (or even if it doesn't) you can re-run with debug logging enabled, and it'll trigger this action where it'll pause the workflow and allow you to ssh into the runner.

      - if: runner.debug == '1'
        uses: mxschmitt/action-tmate@v3

Generally I put it before any critical or likely-to-fail actions.

[falquaddoomi]

Thanks for the comments, @vincerubinetti! FYI, I merged latest main into this branch so that the entrypoint you mentioned would be renamed in this PR; apparently I started this PR before that other one was merged.

Also, just FYI, I tested the function deployment and, after a few tweaks, I was able to deploy gpz-convert-ids successfully. Just for future reference, the changes were the following:

• the cloud-function-deployer service account ("SA") needs to have Service Account User permissions on the SA that runs the function, i.e. logging-monitoring
• the GH action I was trying to use apparently isn't compatible with Gen 2 functions, which is strange since they've been GA for 2+ years now...anyway, the regular gcloud function deploy command that was being used in those deploy scripts works fine, so I switched over to that.

[falquaddoomi]

Well, couldn't test much with a fake GCP key, but it seems to look as expected.

Suggestion: I've been adding this to all my workflows now because it's very handy. If a job fails (or even if it doesn't) you can re-run with debug logging enabled, and it'll trigger this action where it'll pause the workflow and allow you to ssh into the runner.

      - if: runner.debug == '1'
        uses: mxschmitt/action-tmate@v3

Generally I put it before any critical or likely-to-fail actions.

Neat! I put it before the deploy line in the function deploy helper workflow, since I could imagine us wanting to investigate the filesystem if a deploy failed or if the function was acting strangely.

Kind of a small thing: I'm using the GitHub Actions extension for VS Code, and it flags the line - if: runner.debug == '1' as a warning with the message Context access might be invalid: debug. Any idea if that's something that can be safely ignored, or if there's maybe alternate syntax that won't show the warning?

[vincerubinetti]

Hmm idk what that warning is about but I've never had that action throw an error in any workflow, debug mode or not.