Skip to content

Conversation

dscho
Copy link
Member

@dscho dscho commented Sep 2, 2025

To support projects other than Git, the idea is to:

  1. fork the upstream repository (upstream-repo) into a new org where PRs can be handled by GitGitGadget (pr-repo)
  2. mirror the upstream mailing list as a public-inbox repository (if the upstream project does not maintain one themselves, this will have to be maintained in addition to the GitGitGadget instance)
  3. fork gitgitgadget-workflows into the same, new org
  4. configure the project-specific settings via the CONFIG repository variable (using the original project settings as template)
  5. initialize the GitGitGadget state (by running the workflow added in this here PR)
  6. fork gitgitgadget-github-app into the same, new org
  7. create a new Azure Function
  8. deploy the gitgitgadget-github-app fork to that Azure Function
  9. register a new GitHub App with that Azure Function's URL as webhook event receiver
  10. for technical reasons, deploy the Azure Function a second time

I went through these motions, targeting the Cygwin project, and successfully /submited the first patch that way.

This PR is stacked on top of #13 and requires gitgitgadget/gitgitgadget#1995 to be merged first.

The grand idea to use GitGitGadget for projects other than Git is to
allow configuring it via a custom JSON that is stored as a repository
variable.

Let's do this.

Signed-off-by: Johannes Schindelin <[email protected]>
The grand idea to use GitGitGadget for projects other than Git is to
allow configuring it via a custom JSON that is stored as a repository
variable.

Let's do this.

Signed-off-by: Johannes Schindelin <[email protected]>
… Actions

The GitHub Actions of GitGitGadget just learned the trick to accept the
project configuration as an input parameter. The idea is to store this
configuration in the repository variable called `CONFIG`. Here is the
code change to make use of this repository variable.

Obviously, this means that the workflows should no longer run in forks
without said configuration.

For details about configuring GitGitGadget to support projects other
than Git, see TBD.

Signed-off-by: Johannes Schindelin <[email protected]>
With my current push to let GitGitGadget work for other projects than
Git, it is no longer appropriate to refer to the `git` repository forks
directly.

Signed-off-by: Johannes Schindelin <[email protected]>
We just started to pass the project-specific configuration stored in the
`CONFIG` repository variable to the GitHub Actions of GitGitGadget.

That configuration contains information about the correct repositories
to target (which might not be `gitgitgadget/git` and friends). Let's use
this information when obtaining (and using) the installation access
tokens.

This is especially necessary when creating and updating that Check Run
in `handle-pr-push` and in `handle-pr-comment`.

Signed-off-by: Johannes Schindelin <[email protected]>
These should be taken from the project config which is now expected to
be present as the `CONFIG` repository variable.

Signed-off-by: Johannes Schindelin <[email protected]>
So far, GitGitGadget has supported one project, and one single project
only: the Git project.

But the Git project is far from the only one that prides itself by doing
patch review on a mailing list.

To allow GitGitGadget's convenience of PRs being sent to mailing lists
to benefit other projects, too, here is a workflow that will have to be
triggered to initialize the prerequisite Git notes in the `pr-repo`.

For details about setting up GitGitGadget to support a project other
than Git, see TBD.

Signed-off-by: Johannes Schindelin <[email protected]>
@dscho dscho force-pushed the initialize-git-notes branch from a252d88 to 3caaa47 Compare September 5, 2025 06:22
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