Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

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

Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

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

Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

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

Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

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

Implicit configuration is a recipe for confusion when trying to allow
for overriding said configuration. Let's require the config to be passed
down explicitly.

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

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>

The idea is to configure GitGitGadget via a repository variable `CONFIG`
that contains the `IConfig` as JSON, and then pass it 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 `gitgitgadget`,
`gitgitgadget-github-app` and `gitgitgadget-workflows`.

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.

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

GitGitGadget stores its information in Git notes that are pushed to the
`pr-repo`. These notes need to be initialized before any 3rd-party
project can be handled by GitGitGadget.

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

This Action exposes the newly-added functionality to create the initial
set of Git notes that GitGitGadget needs in order to persist its state.

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

Now that we've moved to GitHub Actions, there isn't much of a point left
to keep `misc-helper` around, really, and certainly not the `--config`
option. Besides, it is the last user of `setConfig()`, so let's drop it
before dropping that function.

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

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