simp / simp/gha-workflows

Migrate puppet_create_release_tag.yml to the GitHub App token (step toward retiring simp-auto)

Open
#8 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
0
Forks
0
Avg merge
4h 25m
Merged PRs (30d)
7

Description

What

Migrate puppet_create_release_tag.yml from the simp-auto PAT to the org-owned GitHub App, as org_sync_forks.yml already does (#6).

Why

SIMP_AUTO_GITHUB_TOKEN__REPO_SCOPE belongs to the simp-auto user account, and we no longer hold its credentials. Regaining them would mean a password reset, which risks invalidating the PATs that 74 repos depend on for releases. The App removes that dependency without touching the account.

The App is also strictly better on the merits: org-owned rather than tied to a user, one-hour installation tokens instead of a five-year-old static PAT, Contents/Workflows/Actions write instead of the coarse classic repo scope, and it can be named in ruleset bypass lists — which no PAT scope can achieve.

The change

Mirror what org_sync_forks.yml does:

    env:
      APP_ID: ${{ secrets.SIMP_APP_ID }}
    steps:
      - name: 'Mint a GitHub App installation token'
        id: app-token
        if: env.APP_ID != ''
        uses: actions/create-github-app-token@v2
        with:
          app-id: ${{ secrets.SIMP_APP_ID }}
          private-key: ${{ secrets.SIMP_APP_PRIVATE_KEY }}
          owner: ${{ github.repository_owner }}

then use ${{ steps.app-token.outputs.token || secrets.SIMP_AUTO_GITHUB_TOKEN__REPO_SCOPE }} at the three current reference sites (the actions/checkout token: at line ~70 is the load-bearing one, since the tag push inherits it).

The workflow_call contract needs SIMP_APP_ID / SIMP_APP_PRIVATE_KEY declared in secrets:. They are org-level secrets, so the 67 existing shims keep working unchanged — secrets: inherit passes whatever exists, and no per-repo change is required.

Verify this first — it is the whole reason a PAT was used here

The workflow's own header says:

A PAT is required in order for the pushed tag to trigger the tag_deploy.yml workflow (events created with the workflow's own GITHUB_TOKEN do not trigger other workflows).

That restriction is specific to GITHUB_TOKEN. GitHub App installation tokens are expected to trigger workflows, but that has not been proven in this org yet — the fork-sync job doesn't push tags, so nothing so far exercises it.

Prove it on one repo before merging: push a real (or throwaway) tag using an App token and confirm tag_deploy.yml actually fires. If it does not, this migration cannot proceed as written and the simp-auto sunset needs rethinking — so it is worth settling early rather than after the puppetsync templates move.

Sequence

  1. Prove tag-triggers-workflow with an App token on one repo.
  2. Land this change (single file, 67 shims unaffected).
  3. Then migrate the three puppetsync tag_deploy* templates — 74 deployed copies, tracked separately in simp/puppetsync.
  4. Only once nothing consumes it, sunset simp-auto. At that point a password reset is harmless.

Related

  • #6 — the same migration for org_sync_forks.yml, already merged and verified end to end (13 forks synced, 0 failures, including 5 that the PAT could not sync because it lacks the workflow scope).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with .github/workflows/puppet_create_release_tag.yml and compare its token handling with org_sync_forks.yml. First verify on one repository that a tag pushed with the GitHub App installation token triggers tag_deploy.yml; then update the workflow_call secrets and the three existing token references. Done means the trigger is confirmed and all 67 shims remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, devops
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.