Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: gitgitgadget/gitgitgadget
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: main
Choose a base ref
...
head repository: gitgitgadget/gitgitgadget
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: check-run-action
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 18 commits
  • 24 files changed
  • 1 contributor

Commits on Oct 7, 2025

  1. Extend the IConfig interface as needed for 3rd-party projects 

    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>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    62fce79 View commit details
    Browse the repository at this point in the history

  2. IConfig: rename the attribute defining the upstream-repo's org 

    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>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    23c6d23 View commit details
    Browse the repository at this point in the history

  3. IConfig: move repo.owners to a better place 

    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>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    9890596 View commit details
    Browse the repository at this point in the history

  4. Actions: accept the config input 

    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>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    211dbb2 View commit details
    Browse the repository at this point in the history

  5. Install typia 

    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.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    24a0e2a View commit details
    Browse the repository at this point in the history

  6. npx typia setup 

    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    255ece3 View commit details
    Browse the repository at this point in the history

  7. CIHelper: validate the user-provided config Action input 

    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>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    a603513 View commit details
    Browse the repository at this point in the history

  8. IConfig: avoid "anonymous types" 

    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>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    e68da6a View commit details
    Browse the repository at this point in the history

  9. Include the LintCommit configuration in IConfig 

    This way, the maximal number of columns can be configured freely per
project, via the project-specific config.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    d25eafa View commit details
    Browse the repository at this point in the history

  10. /submit: use correct URL in the "Submitted as" message 

    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>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    07b2da3 View commit details
    Browse the repository at this point in the history

  11. parsePRCommentURLInput/parsePRURLInput: reuse pullRequestKey machinery 

    There was prior art that I should have used, as pointed out in
#1991 (comment)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    d182e11 View commit details
    Browse the repository at this point in the history

  12. CIHelper: move the Dugite prep a bit later 

    In the next commit, I want to add a code path to the `setupGitHubAction()`
method that does not require Git at all, hence it is unnecessary to
prepare for calling Dugite. So delay that prep code.

This commit is best viewed with `--color-moved`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    ee24134 View commit details
    Browse the repository at this point in the history

  13. Add a way to create/update Check Runs 

    In `gitgitgadget-workflows`' 81a4f4d (handle-pr-comment/handle-pr-push:
create a Check Run in the PR, 2025-08-19), I added logic to two
workflows that create and update Check Runs.

This logic is necessarily a bit repetitive (and disrupts the flow when
reading those workflow definitions). So let's move the logic into the
`gitgitgadget/gitgitgadget/check-run` GitHub Action.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    a61a27c View commit details
    Browse the repository at this point in the history

  14. check-run: use a reasonable default for details-url 

    The details URL should in almost all cases point to the current workflow
run. So let's do that by default!

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    eba8635 View commit details
    Browse the repository at this point in the history

  15. check-run: use Typia for type checking 

    This not only makes the validation more robust, easier to read (and
verify the logic), but also prepares for persisting the parameters in an
Action state so that subsequent calls to the Action can update, say, the
text, without having to re-specify all of the parameters.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    5053061 View commit details
    Browse the repository at this point in the history

  16. check-run: use Typia for type checking 

    This not only makes the validation more robust, easier to read (and
verify the logic), but also prepares for persisting the parameters in an
Action state so that subsequent calls to the Action can update, say, the
text, without having to re-specify all of the parameters.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    911a259 View commit details
    Browse the repository at this point in the history

  17. check-run: persist parameters in an Action state 

    ... and reuse it when called a second time. That way, one can update,
say, only the text, without having to re-specify all the details
_again_.

For technical details, the token and the config _do_ need to be
re-specified again (the token because of security concerns, the config
so that the appropriate token can be used just in case that pr-repo and
upstream-repo can be handled by the same workflow).

Note: Instead of using `core.saveState()`, the state is explicitly
persisted via the environment variable `STATE_check-run` (yes, it _is_ a
funny name). The reasons for that are:

1. Subsequent invocations of the Action would _not_ get the state, only
   the `post` Action would.
2. The `post` Action would only receive the state saved by the _first_
   Action invocation, subsequent `saveState()` calls would be ignored!

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    2096531 View commit details
    Browse the repository at this point in the history

  18. check-run: automatically update the conclusion in a post step 

    In a GitHub Action it is possible to register a `post` Action which will
run, if the main Action has been run in a GitHub workflow's job, as an
extra step after all the regular steps have been executed (or skipped).

This presents a fine opportunity to mark the the Check Run as completed
_automatically_, without the need to call the Action _again_.

By adding a new input called job status and filling it automatically
with -- you guessed it -- the job status, we can even automatically
determine the conclusion (I verified manually that this will receive the
expected value in the `post` Action).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    @dscho
    dscho committed Oct 7, 2025
    Configuration menu
    Copy the full SHA
    bc996ad View commit details
    Browse the repository at this point in the history
Loading