Configurable configuration branch/commit messages

[maximilian-krauss]

What would you like Renovate to be able to do?
I would like to be able to configure the title and message of the configuration commit message and pull request. The reason is that we are having push rules on all of our repositories which makes it hard to setup renovate for a large number of projects.

Describe the solution you'd like
Make the configuration commit message title and branch name as configurable as it is already possible for the regular pull requests (commitMessagePrefix, branchPrefix ...)

Or is there a technical reason not to do this?

If this is something you would consider useful, I could provide the pull request 😉

Cheers,
Max

[rarkins]

are you running your own bot?

[maximilian-krauss]

Sort of, I'm runnig the docker image in a gitlab CI pipeline

[rarkins]

Can you give me an example of what you want to change? e.g. a Before/after example?

[maximilian-krauss]

Code wise? There I'm not sure yet but there are options for configuring the commitMessagePrefix which works well for ordinary Pull Requests and I would change it in a way that it would also be considered here: https://github.com/renovatebot/renovate/blob/master/lib/workers/repository/onboarding/branch/rebase.js#L9

Does this makes sense?

[rarkins]

I mean an example of what commit message and what PR title would you use instead of the current ones?

[maximilian-krauss]

Ah I see. Currently the commit messages reads Add renovate.json but we need to have an Jira ticket referenced in every commit (don't ask, enterprises 🤷‍♂). Therefore the commit message should look like FOO-123: Add renovate.json. I mean this feature request is very specific, I guess I'm doing it anyway it's just a matter if you think it would be useful to have it back in the original codebase 🙂

[rarkins]

I think making the onboarding part configurable may be useful to others. I haven't worked out the best way to do that though. If it's the commit message only then it's much safer then the PR title or branch name, because those are like "keys" we just to look up if a repo is already in the progress of being onboarding. Change those, e.g. via config, and you may essentially "reset" your onboarding.

[rarkins]

One possibility is we introduce a new admin configuration object called onboarding and we let commitMessage, branchName and prTitle be overridden there.

[adam-moss]

We had a similar challenge, I worked around it by setting onboarding: false in the config.js for my Renovate pipeline, along with autodiscover: true, and just have the devs add the bot account to their repo/group when they're ready to onboard. They only need to add a renovate.json to their own repo's if there is something they want to add or override to the "corporate" config (e.g. who to assign issues, approvals to etc).

[maximilian-krauss]

@rarkins that sounds like something useful. I could try to implement such an approach if you don't mind.

@adam-moss thanks, will try this in the meantime 👍

[rarkins]

@maximilian-krauss you'd be very welcome to contribute! Here's the basics of what I think we need to do:

1. Change the definition of the existing onboarding object to be an object instead of boolean. It's default value can start with { enabled: true }

2. We might need to add a migration rule to this. I'm not sure if our migration script works on bot-side config though, so if it's not easy to do then we can make it a breaking release and note to use the following migration:

onboarding: true -> onboarding: { enabled: true }
onboarding: false -> onboarding: { enabled: false }

3. Rewrite the existing config.onboarding logic to look for config.onboarding.enabled instead.

4. Add prTitle, branchName and commitMessage fields to onboarding, set to Configure Renovate and {{{branchPrefix}}}/configure and Add renovate.json respectively.

5. Update all references or hardcodings to these values to use config.onboarding.x instead

6. Update docs accordingly