Consume project-specific settings from the CONFIG repository variable
#13
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 2, 2025
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]>
|
@webstech for the record: I updated the PR description with the new idea to maintain a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, GitGitGadget supports only PRs for the Git project. However, there was already a ton of work to encapsulate project-specific information via the
IConfiginterface.Let's move this config to the
gitgitgadget-workflowsrepository.Ideally, we would just add it as a file into the main branch. However, this is a violation of the separation of concerns where the workflows are meant to be generic, yet the config is project-specific. That is, the workflows should be identical in all the forks, but the config absolutely not. The config should be very specific.
Theoretically, we could play games with subdirectories that are named like the forks' organization, or something like that. However, that would create a lot of merge conflicts when synchronizing with upstream, which is a major maintenance headache.
Therefore, the config must be separated from the workflows, and cannot live on the main branch.
One option is to store it in the
CONFIGrepository variable. This offers the convenience of being able to use them directly and GitHub workflow definitions.A major disadvantage, however, is that repository variables are highly intransparent: Only administrators can view and modify them. There is no way to open a pull request to change the config in there. Cross-repository access is finicky (
GITHUB_TOKENlacks the permissions...).An alternative would be to store the config in a dedicated branch, say,
config, where basically just this config lives, in a file, say,gitgitgadget-config.json, that can be viewed by anyone, that can be modified via pull requests, and forked and merged and pulled. Unfortunately, there is no convenient way to use that file in a GitHub workflow definition. For example, when defining a matrix job, the YAML has access to thevarsbut not to any "random blob on a random branch".So why not have the best of both worlds? Maintain the config in that file on that branch. Add automation to validate it in pull requests and to automatically synchronize it to the repository variable when the branch is pushed.
I already took the liberty of pushing it to the
gitgitgadget-workflows/gitgitgadget-workflowsrepository. It successfully validated the config and synchronized it to theCONFIGrepository variable.There is currently a temporary commit at the tip of the
configbranch, to use thevalidate-configGitHub Action from my fork ofgitgitgadget/gitgitgadget(because that Action has not yet been offered via a PR). I will remove this commit and force-push that branch once that Action is merged.With these prerequisites, we can stop hard-coding a lot of project-specific settings in this here repository, and instead consume the settings from
vars.CONFIG.This PR is stacked on top of #12, and also requires gitgitgadget/gitgitgadget#1991 to be merged first.