PR Processor changes to set Redmine status

tl;dr: The new PR processor now updates Redmine fields like Status (to Ready for Testing, set assignee, PR link). The old app no longer does. If you see odd things, please report them.

Longer version:

A long time ago (PR Processor Next Generation) I started rewriting the PR processor, but I never completed the migration. We recently started to notice that the old version is slower and slower. This lead to conflicts in Redmine (typical race condition: one bots sets Fixed in version, the other clears it).

The PRs in question are:

Please let me know if you see something odd.

The only functionality remaining now is setting labels (Waiting on Contributor, Needs testing, etc). That should also be migrated in time.

2 Likes

I have a pr which is based on a different pr. so the commits are:
Fixes #31459 - Add advanced template input to job wizard
Refs #31459 - remove autofill for password, add number validation
Refs #31459 - fix enter key anywhere opens first field
Refs #31459 - fix number validation
Fixes #31460 - add description field to job wizard
And when I updated the newer pr, redmine #31459 got another pr link which wasn’t there before (the commits were the same)
Does this count as “odd”?

I wouldn’t say that’s odd since I think that the old bot did the same thing. Or at least, the logic there was also to iterate over all Redmine issues found in a PR. I don’t think there really is a way to avoid that.

I did notice that it was a draft and maybe that’s something we can teach the bot. Still, you do want the PR to be linked so anyone looking at an issue knows to look at it so probably not really a solution either.

That said, IMHO a draft PR certainly doesn’t mean it should be in Ready for Testing. Assigned at most. Is that something we should teach the bot?