Kallithea issues archive

The design is currently that this configuration is managed from the web UI in /_admin/settings/hooks and stored in the database.

Hooks can be setup via the web UI.

@Mads Kiilerich

Would a pull request ok that adds an entry to a hgrc file into my.ini?

That hgrc file could be fetched here, too: https://kallithea-scm.org/repos/kallithea/files/default/kallithea/lib/utils.py#L355

‌

By the way… the order of hook are important for us. But the WebUI do not provide a stable order. First added one will be executed first but will be ordered alphabetically in the WebUI. That’s confusing. Also it is not possible to provide additional data like for “commitsigs” extension with the WebUI.

Hmm.

It is indeed a bit odd and inconsistent that Kallithea read .hg/hgrc but not "global" config files. It could make sense to support the same as hg help config.files.
Instead of adding more Kallithea config options, I would perhaps rather move in the direction of fixing that.

One argument against reading global config could be that the "global" config might contain settings that only are intended to be used when working on files outside the repo store. Repos inside the repo store shouldn't be touched manually and their hgrc should thus be empty, so there is less risk there.
The risk is that some settings can change hg behaviour so much that Kallithea doesn't work correctly. And that some users might have old cruft in their config that might pop up when upgrading.

We would probably have to modify make_ui so it use the whole config reading mechanism from hg, but for some settings provide defaults if nothing has been set, for other settings override them.
I don't see the point of the ui_sections whitelist - I think we just can remove it.

For hook order, I guess the simplest solution is to make sure hooks configured in UI are shown and executed in the same order: alphabetically. Ordering can then be controlled by choosing names. Full support for "priority" in UI seems like more trouble. But with the solution above, you can just put your custom hooks in a config file instead.

Would that work for you?

Thanks!

Yes, that will work for me. I added that config value because it looks like it is not wanted to use global config file. And the whitelist seems odd, too.

‌

Yes, an alphabetically hook order is ok for us.

‌

‌

Please see https://kallithea-scm.org/repos/kallithea/pull-request/242/_/rework_Thomas_changes_and_some_hgrc - the last 4 changesets. Pull and test if it works for you.

Regarding the last proposed commit that will also read the system user’s .hgrc file: I’m not really a fan of this idea.

Today, the Kallithea setup/configuration is fully contained in the database, the .ini file and the repositories. There is no impact from other configuration files from the system user’s home dir. Only exception is when enabling SSH, in which case the ~/.ssh/authorized_keys file becomes relevant.

My arguments are that such dependency on ‘external’ configuration files is not something that can be evidently expected, specifically because the same configuration file .hgrc is also used outside the Kallithea context. The same system user may need to access other mercurial repositories, not part of Kallithea, and using different settings. It is even the case that they may need certain settings in that other context, which would be harmful for the Kallithea context.

In my opinion, the main goal of this issue is to allow specifying mercurial configuration in a standard syntax like that of the hgrc file, but the fact that it is in an actual standard file is secondary. As an alternative, I would propose a UI textarea field, which would be saved in the database, and which would be treated as an hgrc snippet. The end result will be the same, but restricting its impact to the Kallithea context.

Would such approach cover your needs too?

We have a special mercurial repository that contains the “server hook” configuration and the gnupg truststore. So everything (the hooks, hgrc, …) is signed and in a real repository with a history. After a new (signed) push the content will be populated to the server config. So you have a little “chain” of security. That is much more traceable in a security manner.

Your approach could not satisfy that. But, yes, I could live with your approach, too. Even it isn’t fully automatic and “signed” anymore.

‌

What about a hgrc file next to the kallithea ini file (just thinking out loud)?

If that could be a symlink, yes. That should work.

@Mads Kiilerich What would you think of such a file, e.g. ‘kallithea.hgrc’ in the same place where the ini file is?

Today, the Kallithea setup/configuration is fully contained in the database, the .ini file and the repositories.

That is not wrong, but it should be made very clear that the .hg/hgrc for each Mercurial repo will overrule what is in the database. (And thus I find it inconsistent if we read .hg/hgrc file but don’t read all the other hgrc files.)

Also, I find it least surprising if Mercurial also use global configuration when used from Kallithea: Mercurial configuration generally live in global configuration (as all Mercurial documentation tells) and I expect that most setups will want same setup for manual interaction with Kallithea repositories and for Web interaction with Kallithea repositories.

A different solution to use cases in this area would be something like https://kallithea-scm.org/repos/kallithea-incoming/changeset/4f441d817890b71698384cfaefae66b179f9a234 to help doing bulk inserts into the database. But I can also see some advantages of the opposite: dumping database content to a hgrc file that could be %included . Or perhaps to maintain these settings in the config file instead of in the database.

*If* aiming for a custom hgrc file for Kallithea, I would prefer a .ini setting called something like hgrc_path that make_ui could pass to baseui.readconfig() if set. People could set that to point at ~/.hgrc or a file that %include several global files. A hardcoded hgrc filename doesn’t seem like a good solution.