Conversation
lib/project-config.ts
Outdated
| export interface IRepoConfig { | ||
| name: string; // name of the repo | ||
| owner: string; // owner of repo holding the notes (tracking data) | ||
| baseOwner: string; // owner of upstream ("base") repo |
There was a problem hiding this comment.
@webstech since I started referring to the corresponding repository as upstream-repo, what would you think about the idea to rename this from baseOwner to upstreamOwner?
There was a problem hiding this comment.
I have no issue with renaming. My choice in names may not always be as git oriented as they could be.
There was a problem hiding this comment.
For the record, I am going forward with this: dscho@2de5309
lib/project-config.ts
Outdated
| owner: string; // owner of repo holding the notes (tracking data) | ||
| baseOwner: string; // owner of upstream ("base") repo | ||
| testOwner?: string; // owner of the test repo (if any) | ||
| owners: string[]; // owners of clones being monitored (PR checking) |
There was a problem hiding this comment.
@webstech what do you think about the idea to move this attribute to IAppConfig and to rename it to installedOn? That way, the repo still can have an upstreamOwner on whose repository, however, GitGitGadget is not installed...
There was a problem hiding this comment.
This is used several times in CIHelper so the location could be justified. On the other hand, move it if you like.
There was a problem hiding this comment.
Here is the in-development patch to do so: dscho@9c2e794.
|
Note to self: check whether |
|
An aside while I was looking at this, I noticed |
In gitgitgadget/gitgitgadget#1991, I adjusted and augmented the `IConfig` interface a bit. Concretely, I renamed `repo.baseOwner` to `repo.upstreamOwner` in 2de5309e (IConfig: rename the attribute defining the `upstream-repo`'s org, 2025-09-08) and moved `repo.owners` to `app.installedOn` in 9c2e7944 (IConfig: move `repo.owners` to a better place, 2025-09-08). Let's adjust to that new schema. Note: the `baseOwner` and `owners` attributes are left as-are, for the transitional period until that PR and its friends are merged. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
True! I have implemented that (still need to clean up the branch thicket, it needed fixes): dscho@8b3badb
Okay, this does not work:
as textSadness! Even more sad is the excuse of a documentation of |
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In gitgitgadget/gitgitgadget#1991, I adjusted and augmented the `IConfig` interface a bit. Concretely, I renamed `repo.baseOwner` to `repo.upstreamOwner` in c374c542 (IConfig: rename the attribute defining the `upstream-repo`'s org, 2025-09-08) and moved `repo.owners` to `app.installedOn` in 907807fb (IConfig: move `repo.owners` to a better place, 2025-09-08). Let's adjust to that new schema. Note: the `baseOwner` and `owners` attributes are left as-are, for the transitional period until that PR and its friends are merged. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
@webstech would you kindly have a look? |
There was prior art that I should have used, as pointed out in gitgitgadget#1991 (comment) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
The commit message Review is done. |
The `todo` branch is completely divergent from Git's `master` branch, and as such contains different files. Yet it still belongs to the Git project... This is needed to fix the `Unrecognized project` error in https:// github.com/git/git/pull/2209 The underlying logic was correct until c72d162 (project-options: handle shallow worktrees gracefully, 2024-01-01) broke it; This change was needed to allow migrating from running on a self-hosted Azure Pipelines runner to running on hosted GitHub Actions runners, but the logic was incomplete and would no longer reliably detect whether GitGitGadget is running in a PR that targets the Git project. Another fix would have been to move forward with the `vars.CONFIG` idea championed in #1991. However, my attention was directed away from that effort for a long time now, and it won't be _so_ easy to push that over the finish line. Let's unblock the contributor first. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `todo` branch is completely divergent from Git's `master` branch, and as such contains different files. Yet it still belongs to the Git project... This is needed to fix the `Unrecognized project` error in https:// github.com/git/git/pull/2209 The underlying logic was correct until c72d162 (project-options: handle shallow worktrees gracefully, 2024-01-01) broke it; This change was needed to allow migrating from running on a self-hosted Azure Pipelines runner to running on hosted GitHub Actions runners, but the logic was incomplete and would no longer reliably detect whether GitGitGadget is running in a PR that targets the Git project. Another fix would have been to move forward with the `vars.CONFIG` idea championed in #1991. However, my attention was directed away from that effort for a long time now, and it won't be _so_ easy to push that over the finish line. Let's unblock the contributor first.
In my endeavor to support projects other than Git, I am currently adapting GitGitGadget to allow sending Cygwin PRs to the Cygwin-patches mailing list. I identified a couple of gaps in the project configuration when setting up stuff in https://github.com/cygwingitgadget. Let's close those gaps. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We've settled on the nomenclature `upstream-repo` to refer to the original repository of the project, as opposed to the `pr-repo` which is a fork that exists exclusively to let GitGitGadget handle PRs in (and to store its global state in the Git notes). So let's call the owner of the `upstream-repo` the `upstreamOwner`, not the `baseOwner`. Besides, with GitHub's naming conventions referring to the branch a PR targets as the "base", it is a bit confusing to have `baseOwner` to refer to anything except the owner of the repository in which the PR lives. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `owners` array refers to a list of orgs/owners where the GitHub App is installed, i.e. where GitGitGadget can operate. Therefore, a much better place is `app.installedOn`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea is to configure GitGitGadget via a `gitgitgadget-config.json`
file that contains the project-specific instance of the `IConfig`
interface, tracked in the `config` branch of a fork of the
`gitgitgadget-workflows` repository, from where it is automatically
synchronized via a GitHub workflow to the repository variable `CONFIG`,
and then passed to all of GitGitGadget's Actions via:
```yml
config: '${{ vars.CONFIG }}'
```
For now, this input is optional, to ease the transition of GitGitGadget;
Eventually, this config will be required, so that several projects can
be served using identical source code in forks of the
`gitgitgadget-github-app` and `gitgitgadget-workflows` repositories.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
4f91d43 to
5b1166f
Compare
|
Sorry for the delay. I essentially ran into a large problem and then failed to find the time to fix it until yesterday. The result of this investigation can be found here: #2157 Now I finally implemented the promised changes, rebased onto Range-diff relative to previously-reviewed branch
A lot of churn in |
package.json
Outdated
| "typescript": "^5.9.3", | ||
| "typescript-eslint": "8.56.1" | ||
| "ts-patch": "^3.3.0", | ||
| "typescript": "~5.9.3", |
There was a problem hiding this comment.
Did you intend to switch to this more restrictive updating?
There was a problem hiding this comment.
Not really, that was Typia's setup... Let me undo it, and hope that it does not break anything in the future (read: that Typia requires tighter coupling to Typescript versions). If it breaks, we will find out soon enough.
GitGitGadget now accepts the project configuration as a `config` Action input, in the form of a string that contains the JSON-encoded `IConfig` object. That is a bit fragile, though, as it is all-too-easy to have a typo in that object. Let's install `typia` to use the `IConfig` interface as a source of truth when validating the user input. In a slight variation of what is recommended at https://typia.io/docs/ setup/, I ran: npm install --save-dev typia npx typia setup Then, I undid the damage done to `tsconfig.json` ;-) (`npx typia setup` edited that file and wanted to add just a plugin, but changed plenty of white-space, getting utterly confused by the commented-out lines.) Finally, to fix running the tests via `ts-jest`, I needed to force it to use `ts-patch`, which unfortunately runs into problems because of 281204b (fix: set isolatedModules true for ts-jest, 2025-11-05), because the `ts-patch` transformation is only triggered with `isolatedModules: false`: "compiler": "ts-patch/compiler", "tsconfig": { "isolatedModules": false }, Sadly, this spits out the warning "ts-jest[config] (WARN) message TS151002: Using hybrid module kind (Node16/18/Next) is only supported in "isolatedModules: true". Please set "isolatedModules: true" in your tsconfig.json. To disable this message, you can set "diagnostics.ignoreCodes" to include 151002 in your ts-jest config. See more at https://kulshekhar.github.io/ts-jest/docs/getting-started/ options/diagnostics". We abide by that suggestion: "diagnostics": { "ignoreCodes": [151002] }, Note that `npx typia setup` also switched the version coupling from "typescript": "^5.9.3" to "typescript": "~5.9.3" but we do not want that, so I undid that change in `package.json` and `package-lock.json` manually. Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This uses the freshly-installed `typia` module to create a validator for the `IConfig` interface at compile-time, and uses it to validate user-provided JSON against that interface. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For the `typia`-based validator, it is good to label each and every attribute's type so that the error messages are helpful. This commit is best viewed with `--ignore-space-change`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This way, the maximal number of columns can be configured freely per project, via the project-specific config. To reduce friction for on-boarding new projects by not having to look in multiple locations when creating a config file, the definition of the `ILintCommitConfig` interface is moved to `project-config.ts`, where all the other project-specific interfaces live already. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Currently this URL is constructed from the `host` and the `name` attributes of the project config setting's `mailrepo` attribute. However, the `name` is supposed to refer to the mailing list _mirror repository_, while we are interested in the URL where the web UI of the public-inbox instance lives. Luckily, we already have that in the project configuration: It's the `url` attribute. I noticed the need for this patch in cygwingitgadget/cygwin#1, where the URL displayed after submitting v1 pointed to an incorrect location. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Range-diff
|
…1991), 2026-03-04))

GitGitGadget's GitHub Actions all implicitly use the
defaultConfigthat hard-codes the configuration of the OG GitGitGadget that supports the Git project (and the Git project only).However, for a long time there have been feature requests and musings towards using GitGitGadget also for other projects.
GitGitGadget already does have some beginnings of a support for other projects, e.g. the
IConfiginterface. With these changes, that interface gets extended a little, a validator is added that can verify whether or not an arbitrary object conforms to that interface, and then new inputs are introduced, accepting this (JSON-encoded) configuration as a user-provided string. The idea is that a project-specific fork of https://github.com/gitgitgadget/gitgitgadget-workflows/ contains this configuration in thegitgitgadget-config.jsonfile in a dedicatedconfigbranch, from where it is synchronized via a GitHub workflow to the repository variable calledCONFIG.This somewhat non-trivial setup allows the config to be conveniently tracked via Git, updated via Pull Requests, validated via GitHub workflows, and still to be used in a trivial manner in the main workflows via
${{ vars.CONFIG }}(as opposed to having to play games with multi-branch checkouts orcurl'ing a file from a different branch).This PR is step number 2 in that direction. Step number 1 was to register the
cygwingitgadgetGitHub org for experimenting with GitGitGadget support for a different mailing-list-based project than Git: Cygwin.That org is where I experimented with this change as well as with all the others leading up to gitgitgadget/gitgitgadget-github-app#7.
This PR is stacked on top of #1993 and #1994