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>

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>

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.

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>

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

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

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>

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>

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>

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>

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>

... 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>

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>