Always pass the config as an explicit constructor parameter#1993
Always pass the config as an explicit constructor parameter#1993
config as an explicit constructor parameter#1993Conversation
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>
lib/project-options.ts
Outdated
| baseCommit?: string, | ||
| ): Promise<ProjectOptions> { | ||
| const config: IConfig = getConfig(); | ||
| const config: IConfig = defaultConfig; |
There was a problem hiding this comment.
Should this be passed as a parameter?
There was a problem hiding this comment.
(And sorry for making such a mistake, in my defense, I thought I was still in similar-looking test code, where we do want to use the defaultConfig for reproducible testing.)
There was a problem hiding this comment.
No problem. Will this be going away?
There was a problem hiding this comment.
Yes. Sorry, I forgot to force-push.
There was a problem hiding this comment.
Will this be going away?
Sorry for not being clear. I was wondering if ProjectOptions might go away in the future. It was making GitGitGadget specific decisions but you have added config features that should handle the specific oddities of ggg. For a generic user, the ProjectOptions contains passed values and values from the config project section.
There was a problem hiding this comment.
Oh yes, absolutely. The config handling should all be unified. I mentioned this elsewhere. (I forgot where. There are so many PRs by now. I'm so sorry!)
Definitely lots of opportunities for cleaning up after all that stuff is done, especially to remove the remnants of a CLI interface (GitGitGadget started out as my personal Bash script and for some time I tried to keep them in sync and then I tried to make GitGitGadget fulfill the role of the Bash script by having a compatible CLI interface. But that was a mistake and only lead to needlessly complex code.)
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>
a0244a6 to
39c86ed
Compare
|
Force-pushed. Range-diff
|
…licit-config, 2025-09-08))
…itgadget/explicit-config, 2025-09-08))
GitGitGadget's GitHub Actions all implicitly use the [`defaultConfig`](https://github.com/gitgitgadget/gitgitgadget/blob/153badfc78153bb25d10e0e0d40c2cb3924d7f1b/lib/gitgitgadget-config.ts#L3-L45) that 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 `IConfig` interface. 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 the `gitgitgadget-config.json` file in a dedicated `config` branch, from where it is synchronized via a GitHub workflow to the repository variable called `CONFIG`. 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 or `curl`'ing a file from a different branch). This PR is step number 2 in that direction. Step number 1 was to register the [`cygwingitgadget` GitHub org](https://github.com/cygwingitgadget/) 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
This is necessary so that the project config is reliably passed through, and the
defaultConfigis not used by mistake.This PR is stacked on #1994 and needs that to be merged first.