Add support for GitHub App tokens instead of PAT's

[martijnvankekem]

Because of the configured PAT's, all issues etc. are created by the user that created the Personal Access Token.

I would like to use a GitHub Apps token, so that issues are created by a bot maintained by my organization.

This would require:

• Adding a app_client_id config option, and adding docs stating that the user should create a app_private_key secret (or something similar).
• Adding the action below to each action runner to fetch a App Token:

      - name: Get Token
        uses: actions/create-github-app-token@v3
        id: token
        with:
          # required
          client-id: ${{ config.APP_CLIENT_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}

• Letting subsequent action steps use the fetched token

      - uses: [...]
        with:
          token: ${{steps.token.outputs.token}}

[MLuc24]

Worth adding the argument that makes this need to be upstream rather than something you can do locally, because it's stronger than it first looks.

Nothing in the workflows cares what kind of token it gets. Both places it's used are just:

token: ${{ secrets.GH_PAT || github.token }}

GH_PAT: ${{ secrets.GH_PAT || github.token }}

So an app installation token would work as-is — except you can't get one into secrets.GH_PAT, because that's a static repository secret and installation tokens expire after an hour. They have to be minted per run, which is exactly why your create-github-app-token step is the right shape and why there's no config-only workaround.

The part I'd put in the request, though, is that hand-editing your own workflows doesn't survive. There's an update-template.yml that runs the monitor's template update against your repo, so template-managed files get synced back from upstream. Anyone patching the token step in locally would have it quietly reverted on the next template run, and would then see issues start being authored by the PAT user again without any obvious cause. That makes this a change that can't be done downstream, rather than one that's merely inconvenient — which is a much better position to argue from than "I'd like a bot to author the issues".

One suggestion on shape: the existing secrets.GH_PAT || github.token fallback is a good precedent to follow. If the app step is conditional on the app config being present and the token expression becomes something like the app token, then GH_PAT, then github.token, the change is fully backwards-compatible — existing installs keep working untouched, and nobody has to migrate. Much easier to merge than anything that changes behaviour for current users.

Worth checking uptime-monitor too, since the workflows only pass the token through and the API calls happen in the action. If it does anything PAT-specific like assuming a user identity, that's a second place needing attention, and better found now than after the workflow half is merged.