@dependabot recreate should incorporate config changes in dependabot.yml that happened after the original PR was created

[markusicu]

In some of the unicode-org projects and repos (CLDR & ICU) we require commit messages to start with a specific type of text (project plus Jira ticket number, for cross-linking Jira<->PR). For accepting dependabot changes it would be great if there was an action like @dependabot message prefix my_custom_prefix which used git commit --amend to apply the prefix (and add a space between the prefix and the original message). It could be sticky per repo, for convenience. (We would change it to a different prefix / different Jira ticket number every so often.)

For example, see CLDR & ICU commits:

• https://github.com/unicode-org/cldr/commits/master
• https://github.com/unicode-org/icu/commits/master

[mwaddell]

I believe this has been addressed by https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#commit-message

[markusicu]

I believe this has been addressed by https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#commit-message

Yes, mostly, I think. It looks like we would need to configure a prefix with our usual pattern and some Jira ticket/issue, and remember to update the prefix with a new Jira ticket/issue each time we publish a release and start work on the next one.
With the prefix, the dependabot commit messages should automatically be right. Without a per-pull-request override command, we might still need to manually work around undesirable Jira tickets near release time.

Thanks!

[mwaddell]

You're welcome! Since the prefix would need to be configured before the commit message is initially written, you'd need to maintain it in your dependabot.yml file and change it when you switch milestones (maybe using a github action that runs on a milestone or release event?)

The only other option I can think of would be to write a github action that runs each time a PR is created by dependabot and calls git commit --amend -m "new message" && git push --force to overwrite the message that dependabot created. Your github action could use whatever logic you want to determine the proper commit message to use.

[srl295]

@mwaddell Hi .I got this working in unicode-org/cldr#1895 for CLDR (one of the projects mentioned above). However, it seems that we now get dependency updates (which is great), but @dependabot recreate on the security updates doesn't seem to pickup the updated commit prefix. Is there something we need to do for the security updates?

• Example PR with correct commit message: CLDR-15539 js:(deps-dev): Bump chai from 4.3.4 to 4.3.6 in /tools/cldr-apps/js unicode-org/cldr#1909

• Example where @dependabot recreate did not update the commit message: Bump moment from 2.29.1 to 2.29.2 in /tools/cldr-apps/js unicode-org/cldr#1883 (comment)

We haven't had any new security PRs come in from dependabot, so maybe those will be OK when they come? Let me know if you have any advice, thanks.

[mwaddell]

@srl295 Yes, this is a known issue (#4652) - @dependabot recreate is a bit of a misnomer. It should really be called @dependabot force-rebase. The only difference between recreate and rebase is that rebase fails if there are any additional commits in the branch, while recreate skips that check.

Neither rebase nor recreate actually "recreate" the PR, so the title, labels, etc aren't impacted. The prefix functionality is only called when the PR is initially created.

[jeffwidman]

Many thanks @mwaddell for chiming in here.

I'm going to close because:

1. At this point, I think the original request is mostly addressed.
2. I broke out the idea of clarifying recreate as force-rebase into Rename @dependabot recreate to @dependabot force-rebase #6204.
3. We don't currently have a mechanism for completely rebuilding old PR's with a new config... and it happens rarely enough that I don't see us building that out anytime soon. If it starts being a common user request, then we're happy to re-evaluate.

[srl295]

What's not addressed yet (though we are glad to have dependabot!) is a way to handle that change of targetted ticket and thus commit message, around release time.

I think the reason I thought @dependabot recreate did what I wanted is that the re-analysis sometimes causes a PR to be closed as 'superseded'. That actually gives the desired behavior: a new PR with the correct version info.

[jeffwidman]

Yeah, that request makes sense--essentially you're looking for a "dependabot, please force rebuild the PR using my latest dependabot.yml config, even if the actual package version that's getting pulled didn't change". That's certainly the more intuitive behavior for how I'd expect a @dependabot recreate to work.

Given it doesn't work that way internally today, I'm going to reopen. To set expectations, this probably will be lower priority for a while compared to some of the other stuff we're working on that affects more folks.