No description
If a prior run created the role but failed to write Vault, the next run would generate a new password and store it in Vault — but postgres kept the old one, drifting forever. Now CREATE if missing, ALTER if present, so postgres always matches the Vault-stored password. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| action.yml | ||
| README.md | ||
actions-deploy
Forgejo composite action that mints a short-lived container-registry token
via Forgejo OIDC → Vault and runs docker login git.tamjid.io. Used by
every per-app deploy workflow so they don't all repeat the same 10 lines
of OIDC plumbing.
Usage
jobs:
deploy:
runs-on: home-server
enable-openid-connect: true # required
env:
TAG: ${{ github.sha }}
steps:
- uses: actions/checkout@v4
- uses: https://git.tamjid.io/tamjid/actions-deploy@main # full URL — Forgejo's default actions URL is data.forgejo.org
- run: docker build -t git.tamjid.io/tamjid/<app>:$TAG -t git.tamjid.io/tamjid/<app>:latest .
- run: docker push --all-tags git.tamjid.io/tamjid/<app>
- run: nomad job run -var "tag=$TAG" <app>.nomad
That's the whole deploy. No Vault role per repo (the shared app-build
role accepts any tamjid/* repo). No long-lived secrets in Forgejo.
How it works
The Vault app-build JWT role has:
bound_claims = {"repository": "tamjid/*"}+bound_claims_type = glob— any repo undertamjid/can claim a token.token_policies = ["forgejo-registry-tamjid-read"]— only allows reading the registry PAT atsecret/ci/forgejo-registry/tamjid.ttl = 10m— Vault token expires fast.
If a future app needs additional secrets beyond the registry token (e.g.
the home repo's NEXT_PUBLIC_API_URL), give that one repo its own
narrower role and run the inline OIDC fetch directly (don't use this
action).