Renovate: Configure an explicit value for 'semanticCommits' during onboarding

[edmorley]

What would you like Renovate to be able to do?
For repositories that inconsistently use semantic commit messages style, the Renovate default of auto-detection can cause the issues seen in https://github.com/yarnpkg/yarn/pull/6463#issuecomment-426240070.

Describe the solution you'd like
When Renovate opens the onboarding PR, it could set either semanticCommits: true/false (or the equivalent presets) based on what auto-detection found at the time, so that the mode doesn't flip-flop back and forth in the future.

Describe alternatives you've considered
It might be that it's desirable for Renovate to automatically start using semantic commits mode, if a repository starts using that form permanently in the future - and so pinning in renovate.json not ideal (though IMO I always prefer explicit config over magic behaviour).

If so, perhaps another way to avoid the issues seen in the yarn repository, would be for Renovate to add a warning comment to PRs saying "we notice that there are open Renovate PRs using both styles of commit messages. Please set semanticCommits explicitly to pick which style you'd like".

[rarkins]

Thanks for creating the issue. I was still trying to work out the best approach to this. Previously we actually did fill in semanticCommits in the onboarding PR, before changing to dynamically checking like we do today.

The main downside of non-auto would be that a repo that subsequently takes up semantic commits won't have the bot turn on by default. But at least if there's an explicit setting already in their renovate.json, maybe it reduces the chance of confusion.

A second downside is that we now make the onboardingConfig param empty by default, to allow self-hosted bot users to supply their own config. "config:base" is the "opinionated" default config of the Renovate App service. Any logic for adding an extra field would need to be done inside the bot, which means we need to think of all the possible conflicts, e.g. what if a self-hosted bot admin includes a preset that explicitly turns semanticCommits on, even if the repo has no history of them? We'd need to detect that type of stuff.

[rarkins]

We need to:

• resolve the onboarding config
• if there’s no explicit setting for semantic commits then add one

[bflad]

For what its worth, we have run into a similar problem with semantic commit auto-detection in our repository (flipping on and off) and we are opting to explicitly disable: https://github.com/terraform-providers/terraform-provider-aws/pull/10266

[rarkins]

Two step plan:

1. Add "semanticCommits": true to the onboarded renovate.json if we detect semantic commits
2. In next major release, change default value for semanticCommits from "auto" to "false"
3. Try to work out if we can create a migration PR for everyone before that (not just for semantic commits, but for everything that needs migrating)

[rarkins]

I need to think this through more. Let's say in future we want to default semanticCommits to disabled, instead of auto. i.e. to enable it you need to do so via a preset or per-repo in the renovate.json. How can we support both these scenarios?

1. Someone has an org-wide preset that never use semanticCommits
2. Everyone else, where we wish to detect semanticCommits at onboarding and add it to the config if detected

The problem if we default to 'disabled' is that we can't tell the difference between the person who wants to disable it org-wide versus everyone else who has no preference/config about it.

Possible approaches:

• Support 'enabled', 'disabled' and 'auto' but default to null. Then during onboarding we can detect the difference between null and 'disabled'. If during regular running we find it is null then we default to 'disabled'.
• Make it so that we can determine the difference between repo config vs default values. So (a) take the onboardingConfig, resolve it alone, check if semanticCommits is undefined and if so then set it to 'enabled' if detected.

The second approach seems better, i.e.

• If the onboarding branch is modified, skip modifying it like we always do
• Otherwise, fully resolve the onboardingConfig and check if semanticCommits is defined
• If semanticCommits is undefined, and semantic commits detection returns true, then add it to the onboardingConfig. Otherwise leave it unconfigured

@zharinov @viceice what do you think?