A large part of GitGitGadget's operation runs inside Azure Pipelines, either in a scheduled run, or triggered directly via a push event or indirectly via the GitHub App (which is backed by an Azure Function that performs rudimentary validation and then triggers the Pipeline via a PAT, passing along some parameters).

Azure Pipelines seems to be developed less actively than GitHub Actions, therefore it is desirable to migrate from the former to the latter.

One challenge are the secrets used by the Azure Pipeline: we need to ensure that they stay, well, secret. It is much easier to accidentally leak them by carelessly accepting a seemingly innocuous PR that updates some random CI run (but really is designed to leak an unprotected secret). We might want to use this shiny new tool in the toolbox called "environment secrets", where we can restrict in the GitHub UI which workflows are allowed to access them.

One of the very neat things GitGitGadget does is that it is shown in the "checks" of a PR, i.e. if GitGitGadget is currently preparing a patch series to send or to preview, the PR status is set to "in progress".

The way this is done is by registering the corresponding Azure Pipeline with the repository targeted by the PR. Currently, there are three such Pipelines:

• The GitGitGadget PR Handler Pipeline is associated with gitgitgadget/git
• The GitGitGadget PR Handler (git) Pipeline is associated with git/git
• (For testing only) The GitGitGadget PR Handler (dscho) Pipeline is associated with dscho/git.

Whenever GitGitGadget's GitHub App installed in the respective repository receives an event about an added PR comment (in the form of triggering the Azure Function), it manually triggers the respective Azure Pipeline.

Since the introduction of the workflow_dispatch event, it should be possible to port this strategy to GitHub workflows.

Except.

Except the fact that the triggered workflow would need to be tracked in the repository targeted by the PR (e.g. in git/git, which would most likely be a really hard sell to the Git project, especially when we would need to be super agile to address externally-triggered breakages such as when the ::set-env: method to set environment variables stopped working without much in the way of a warning; The fix would have to be applied super quickly to git/git's master branch, which is contrary to Git's current custom).

The most natural way, however, would be for the workflows to live in gitgitgadget/gitgitgadget. Currently, there is no way GitHub workflows support this idea of the workflow living in a different repository than where it runs.

So let's keep this ticket open, marked as [BLOCKED], until such a time when we can have GitHub workflow definitions that live outside the repository where they are expected to run.