Set up deploys from GitHub Actions: trust policy, deploy role and workflow #1788

Part of HarperFast/create-harper#143.

Problem

Since Harper 5.3.0, a GitHub Actions run can deploy with no stored credential. It trades its OIDC token for a one-hour operation token under a trust policy (HarperFast/harper#2171), and acts as a user whose role can deploy and do nothing else (HarperFast/harper#2809). Studio has nothing for this:

• No trust-policy UI. Studio has no UI for add_oidc_trust, list_oidc_trust or drop_oidc_trust, and these operations aren't in the operations catalog.
• The roles editor is out of date. It marks deploy_component, drop_component, package_component and restart_service as granting nothing on every 5.x (GATE_INERT_OPERATIONS, from role operations allowlist: grants are gate-inert for ops registered without api_name (deploy_component, get_status, …); sql bypasses the allowlist harper#2175). That stopped being true in 5.3.0, so today the editor would tell someone their CI role can't deploy.
• The CLI tab is out of date. New Application → CLI (useCLISteps.tsx) tells people to run npm create harper with --deploymentUsername and save their password in .env. create-harper no longer asks for a username or a password.
• Dead GitHub code. src/integrations/github/ has a repository and tags client that nothing uses.

Proposal

Add a Deploy from GitHub panel to an application, for super users on 5.3.0+.

1. Inputs. The panel asks for:

   • the GitHub repository;
   • the branch (main by default);
   • the environment (production by default);
   • the workflow path (.github/workflows/deploy.yaml by default, as create-harper scaffolds it).

   It resolves the repository's numeric id through GitHub's API. For a private repository, the user pastes the id or grants GitHub access (Use OAuth for accessing private repos for deployment #1312).

2. What it creates. It creates or updates the same three things as npm run deploy:setup-ci (deploy:setup-ci: create the cluster's trust policy and deploy role once create-harper#145), so a project looks the same on the cluster whichever way it was set up:

   • A role with operations: ["deploy_component", "get_job"] and no table permissions.
   • A user in that role, with a random password that is never shown.
   • A trust policy:
     • issuer https://token.actions.githubusercontent.com;
     • audience: the cluster's operations URL, exactly as the CLI requests it, with an explicit port and a trailing slash;
     • claims pinning repository_id, workflow_ref and environment;
     • operations: the same list as the role.

3. What to commit. It shows the workflow file to commit, which is the one create-harper scaffolds (Deploy on merge to main with GitHub OIDC instead of a stored refresh token create-harper#144). It also shows the HARPER_CLI_TARGET value to set as a repository variable.

4. Trust policies list. A cluster-level list of trust policies, from list_oidc_trust. Each entry shows what the policy trusts, the user it acts as and its operations. When a policy can't match anything, the entry shows its invalid_reason. Policies can be dropped, or disabled by saving them with enabled: false, from the list.

Also:

• Make GATE_INERT_OPERATIONS version-aware, so those operations show as inert only before 5.3.0.
• Add the OIDC trust operations to the operations catalog as super-user only. Their handlers enforce that too.
• Update New Application → CLI to the current create-harper flow: harper login, then deploy on merge to main.
• On the Deployments page, mark a deploy made under a trust policy (Deployments page: what is live, where it came from, and how each node took it #1786).

Related

• HarperFast/central-manager#904 creates the same three objects for PR previews, through central manager, with a component-scoped role. Production deploys don't need central manager, because Studio can call the cluster as the signed-in super user, but the shapes should stay the same.
• Scope deploy permissions to component names harper#3046 will let the role be limited to one component.
• Reference: add_oidc_trust and list_oidc_trust.

Done when

A user starts from a new repository and a 5.3+ cluster. They fill in the panel, commit the workflow it shows and set the variable, and the next merge to main deploys with no secret in GitHub. The trust policies list flags a policy that can't match, with its reason.