And after a little testing, we can force push the dependabot branches :) -
https://github.com/xstefank/wildfly/pull/67. So the wildfly-bot can adjust dynamically also the commit message. So just let me know what would be the preferred way of doing this and we can get it done in wildfly-bot.
That's very cool, but my instinct on this is to defer it a bit more to the future so we can experiment more and think about side effects.
More inline below.
Cheers,
Martin Stefanko
Principal Software Engineer
Middleware Runtimes Sustaining Engineering Team
Red Hat
Just a few ideas.
As mentioned in the other thread, wildfly-bot could act as "dependabot" by for instance taking the upgrade report sent to this mailing list and creating PRs with correct format based on it. The question is if the dependabot would perform better or if the report is sufficient in terms of what needs to be upgraded.
Bot can also create JIRA automatically.
Bot can also easily change whatever can be changed in the PR created by the dependabot automatically. So there is no need for manual interventions.
This sounds great. As noted above I feel initially cautious about tweaking the update commit itself, but being able to get automate JIRA filing and adding the JIRA # to the PR title and the JIRA link to the PR description sounds great.
Also, if we can set up potentially automatic merging of PRs if all workflows pass (I know, just a crazy idea).
You're a wild man. :)
My impression is we're pretty good about getting micro component upgrades merged pretty quickly once SMEs have approved them. I'm interested to know if people feel differently. It's the approval that can tend to take time, and often that's due to the need to validate updates against external testsuites, i.e. the project testsuites for the larger components that use the upgrade candidate.
We also have windows around releases where we want strict control over what's being merged.
Cheers,
Martin Stefanko
Principal Software Engineer
Middleware Runtimes Sustaining Engineering Team
Red Hat