renovate-config: tool constraint / constraint commitMessageTopic seems to be hardcoded

[mikeroll]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.39.0

Please tell us more about your question or problem

Taking uv as the example.
Relevant parts of renovate.json5:

{
  "extends": [
    ":semanticCommits",
    ":semanticCommitTypeAll(chore)",
  ],
  "ignorePresets": [
    ":semanticPrefixFixDepsChoreOthers",
  ],
  "commitMessageTopic": "{{depName}}",
  "enabledManagers": [
    "renovate-config",
  ],
  "constraints": {
    "uv": "0.12.3",
  },
}

Expected behaviour:

The PR is titled chore(deps): update uv to v0.12.5

Actual behaviour:

The PR is still titled chore(deps): update uv tool constraint to v0.12.5

Why this is extra annoying

I wouldn't mind the cosmetics that much for isolated PRs. However, in my setup the constraint updates (renovate-config) are grouped together with the actual tool updates (in my case for uv that's done via mise and dockerfile managers).

PR screenshot

Sometimes renovate-config "wins" and the PR is titled (as in the screenshot):

chore(deps): update uv tool constraint to v0.12.5

Sometimes the other, "good citizen" managers "win" and the PR is titled according to my chosen format:

chore(deps): update uv to v0.12.5

[jamietanna]

Yep, this is due to

renovate/lib/modules/manager/renovate-config/extract.ts

Line 90 in c05d35a

commitMessageTopic: '{{{depName}}} tool constraint',

(and other cases in the file)

@RahulGautamSingh do we have a handy way to override this?

[RahulGautamSingh]

matchDepTypes works here.

The manager sets depType: "tool-constraint" (or "constraint"), and packageRules are applied after the dep-level config is merged.

The flip-flopping title in grouped PRs is because the grouped branch takes its topic from whichever upgrade sorts first; making both managers produce the same topic settles it.

[mikeroll]

Thank you! I'll try to mitigate this with matchDepTypes meanwhile.

Would you consider this a bug though? My simplified global "commitMessageTopic": "{{depName}}" got me quite far with most other managers, and it feels like one shouldn't need to dig into things like depTypes of a specific manager to have consistent commit messages.

[RahulGautamSingh]

It makes sense to not hardcode it. @jamietanna wdyt

[jamietanna]

I prefer there to be a default topic - which is why I added it - but if we can do it in a way that doesn't override the branch's config, that'd be better

Might be a more general thing that we need to fix in workers/repository?

[mikeroll]

I had a look around and I see many managers doing

export const defaultConfig = {
  commitMessageTopic: "preferred default topic",
  ...
}

renovate-config (and some others) don't, likely as the default is chosen from multiple options ("tool constraint" or "constraint") at runtime, rather than known statically. After this my current understanding of the codebase hits a limit I'm afraid :)

[jamietanna]

@ChangkeunJ if you're replying to Discussions using AI, please disclose it, or you will be temporarily blocked