Skip to content

feat(sf-org-login): add credential-source gcp, via new gcp-secret-get action - #33

Merged
gambe94 merged 2 commits into
mainfrom
feat/gcp-secret-get-and-sf-org-login-gcp
Aug 20, 2026
Merged

gambe94 merged 2 commits into
mainfrom
feat/gcp-secret-get-and-sf-org-login-gcp

Conversation

@gambe94

@gambe94 gambe94 commented Aug 20, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • New composite action gcp-secret-get: mirrors aws-secret-get's contract exactly — Direct WIF auth (no service account, no key file), fetch a JSON-bundle secret, export every top-level field uppercased + masked. Deliberately generic, no Salesforce-specific knowledge.
  • sf-org-login gains credential-source: gcp — the branch its own header comment has promised since credential-source was introduced ("A future gcp branch slots in beside these two without touching a single caller"). New inputs gcp-workload-identity-provider / gcp-project-id / gcp-secret-name, validated the same way the aws/github-env branches are. A new "Stage credentials from GCP" step remaps gcp-secret-get's generic export (USERNAME/CLIENT_ID/INSTANCE_URL/JWT_KEY) to the canonical JWT_KEY_B64/USERNAME/CLIENT_ID/INSTANCE_URL shape the shared JWT-login step already expects — base64-encoding JWT_KEY, since the GCP bundle stores raw PEM rather than pre-encoded base64 like the other two sources.
  • Extends smoke-sf-org-login.yml with a credential-free rejection case for a missing gcp-workload-identity-provider, matching the existing per-branch coverage philosophy.
  • No breaking changes: every new input is optional with an empty-string default, credential-source still defaults to aws, and the azure-key-vault/unknown-value rejection case is untouched.

This completes design doc Phase 8.4 (sf-org-login's credential-source: gcp branch + gcp-secret-get) from sf-develop-demo's 2026-08-19-salesforce-gcp-secret-manager-design.md. First real consumer is sf-external-app-bootstrap, once gforce-google-infra#2 widens WIF trust to include it.

Test plan

  • actionlint — clean on both changed/new action manifests and the smoke workflow
  • npm run all (format, lint, typecheck, bundle, test, dist:verify) — all green, ran automatically via the pre-push hook
  • smoke-sf-org-login.yml's existing rejection cases unaffected (unknown credential-source, malformed key, auth-url path)
  • This PR's own CI run of smoke-sf-org-login.yml, including the new gcp rejection case
  • End-to-end credential-source: gcp exercised for real once sf-external-app-bootstrap's demo workflow runs (pending gforce-google-infra#2)

🤖 Generated with Claude Code

… Direct WIF

Mirrors aws-secret-get's contract: authenticate via Direct Workload Identity
Federation (no service account, no key file), fetch a JSON-bundle secret,
export every top-level field as an uppercased, masked environment variable.
Deliberately generic — field-name remapping for any specific consumer (e.g.
Salesforce's username/client_id/instance_url/jwt_key shape) belongs in that
consumer, not here. First consumer: sf-org-login's new gcp credential-source.
Completes the "future gcp branch" the header comment has promised since
credential-source was introduced: fetch via the new gcp-secret-get action,
remap its generic USERNAME/CLIENT_ID/INSTANCE_URL/JWT_KEY export to the
canonical JWT_KEY_B64/USERNAME/CLIENT_ID/INSTANCE_URL shape the shared JWT
login step already expects (base64-encoding JWT_KEY, since the GCP bundle
stores raw PEM, not pre-encoded like the aws/github-env sources).

Extends smoke-sf-org-login.yml with a credential-free rejection case for a
missing gcp-workload-identity-provider, matching every other validation
branch's existing coverage.

First real consumer: sf-external-app-bootstrap (Gforce-Innovation-Kft),
once gforce-google-infra#2 lands and its WIF trust widens to include it.
gambe94 added a commit to Gforce-Innovation-Kft/sf-external-app-bootstrap that referenced this pull request Aug 20, 2026
…workflow

New src/syncGcpSecret.ts (+ npm run sync:secret) adds a new version to the
existing salesforce-<env> secret after generate:jwt/setup-app run — always
an upsert, since Secret Manager versions are append-only and callers read
"latest". Never attempts to create the secret container itself: the write
identity (gcp-secrets-admin WIF claim) only has secretVersionAdder, and all
3 known envs already have containers.

New .github/workflows/setup-external-app.yml wires the whole flow end to
end via workflow_dispatch: resolve-env -> setup (read via sf-org-login's
new credential-source: gcp, generate a fresh keypair, create/update the
External Client App, verify JWT login in a container) -> sync-secret
(write the fresh keypair back). Three jobs because a job can only declare
one `environment:`, and read/write use different WIF claims; the new
private key crosses job boundaries as a 1-day-retention artifact, never
committed or logged.

Needs Gforce-Innovation-Kft/gforce-google-infra#2 (WIF trust) and
Gforce-Innovation-Kft/shared-github-actions#33 (sf-org-login's gcp branch)
merged before a real run will get past the login step.
@gambe94
gambe94 merged commit 2d0bcf7 into main Aug 20, 2026
10 checks passed
@gambe94
gambe94 deleted the feat/gcp-secret-get-and-sf-org-login-gcp branch August 20, 2026 16:59
gambe94 added a commit that referenced this pull request Aug 20, 2026
#36)

sf-org-login's action.yml comment already states this; the reference doc
was written before PR #33 added credential-source:gcp and didn't carry it.
Root-caused for real against a live salesforce-devhub secret and a GitHub
Actions run — see gforce-google-infra's docs/SECRETS.md for the seeding
side of the same rule.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant