CI: Update renovate.json to manually enable semantic commits

[echoix]

Closes #3703

I wasn’t set up to test this PR, as is, and like I normally would like. I would’ve needed a clean-ish main branch that I would have been able to push to it, and that the last 10 commits were like here to check the decisions that the tool made. And I would’ve needed that repo to be all configured with renovate to be able to correctly read the logs.

If I remember, having a PR changing a renovate config file triggers a validation check if I’m not mistaken. I should be able to read the logs for this.

[echoix]

I'd like this to be merged, I think it is still the correct way to go. It has low probability of breaking things, and has a higher chance of doing the right thing. The "wrong" thing would be unwanted renovate configuration (like naming), that doesn't really prevent usage of the repo.

[wenzeslaus]

From the linked discussion, I don't get what "ignorePresets": [":semanticPrefixFixDepsChoreOthers"] is doing and the maintainer there says:

The title/premise of this discussion is wrong, I don't think there's any more to look into....If you don't configure it explicitly, renovate will "guess" your semantic commits use based on the last 10 commits. This is a feature and not a bug.

Can you please say "X is happening now because A, but with my change, Y will be happening because B"? Then I can approve it without diving deep into this myself.

[echoix]

I thought that the fact that our PR titles got renamed randomly on rebases was because of a bug, or a change. Then, I observed it wasn't only on rebases, but on new PRs, and also for PRs that weren't new and weren't rebased. But at some point, it stopped being a problem, and later again, PR titles got renamed.

Asking about this, we got pointed to an part of the docs that I didn't know about, that renovate tries to be smart and tries to detect if the repo is using semantic commits convention or not (using the last 10 commits on main, I don't know if they filter for only renovate PRs). That last 10 commits should explain the transient behaviour.

Then, on the explanations and possible fix:
Our renovate config initially used a base preset (117d0de), and then added a config to improve the titles of PRs (d0a9538).
Then we used the "config:best-practices" preset instead of only "config:base" (732383e). The "config:best-practices" extends the "config:recommended" (that we should've had been using instead of "config:base" before upgrading to "config:best-practices").
The first collaborator to answer formulated the hypothesis that a setting in "config:recommended", ":semanticPrefixFixDepsChoreOthers", might be conflicting with ":semanticCommitTypeAll(CI)". If it was the case, ignoring the conflicting preset might solve this.

That collaborator asked for confirmation of a maintainer with more knowledge on the subject, that confirmed that renovate checks the last 10 commits.
I reread the rest of his answer now, and a bit more on other docs, with a fresh mind, and I think I understand what he meant now. I think he is referring to the semantic commit messages doc pages, and that the "If you don't configure it explicitly, renovate will "guess"..." means if we don't manually set semantics commits on or off like https://docs.renovatebot.com/semantic-commits/#manually-enabling-or-disabling-semantic-commits, we would get our behaviour depending on the commits merged on main.
That maintainer then renamed the discussion with another title, since it shouldn't be a bug, but a misconfiguration.

So, I now have a better guess than what this PR suggests (it wouldn't have harmed, but would probably work less than my new idea). Do I make a new PR, or update it?
I think that this has better chances to work, if I finally understood that second answer:

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "extends": [
        "config:best-practices",
        ":semanticCommits",
        ":semanticCommitTypeAll(CI)"
    ]
}

It manually enables the semantic commits instead of relying on auto-detection.

[echoix]

I could also use a json5 file, so we could add comments

[echoix]

What alternative do you prefer? Update this PR or create a new one?

[wenzeslaus]

What alternative do you prefer? Update this PR or create a new one?

Just update this one. No need to restart with only few people involved, medium amount of comments and a clear development of the topic. Thanks for asking.

[wenzeslaus]

I could also use a json5 file, so we could add comments

Comments in JSON files sound great. I didn't look into JSON5, so I don't feel like making the call right now. If renovate supports that and perhaps uses that in examples, then you can just use it as if it would be a tool-specific format without invoking whole new discussion about introduction of new formats. (Having in view that something like JSON with comments has a high chance of broader adoption.)

[echoix]

JSON5 is an extension for json, that is well known in the node.js world and tooling, like configuration files. It allows single and multi line comments, allows trailing commas, and slacks the requirements of the double quotes in the keys, borrowing from the ECMAScript 5.1 syntax. In other words, it allows basic JavaScript syntax for JavaScript objects, but not code. So it just makes sense if you write JavaScript.

[echoix]

I decided to not change the file with comments in this PR, as there isn't much to comment on yet. The renovate docs explain both of them, and has some code blocks with both of them (I saw them this weekend) https://docs.renovatebot.com/getting-started/installing-onboarding/#configuration-location

[echoix]

It worked! See #3715, #3710, #3725, etc.