[wildfly-dev] Re: Turn on dependabot

On Thu, Jul 27, 2023 at 10:39 AM Martin Stefanko <mstefank(a)redhat.com&gt; wrote: > 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 > > > > On Thu, Jul 27, 2023 at 5:27 PM Martin Stefanko <mstefank(a)redhat.com&gt; > wrote: > >> 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 >> >> >> On Thu, Jul 27, 2023 at 4:37 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Thu, Jul 27, 2023 at 1:56 AM Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: >>> >>>> Hi Brian, >>>> >>>> > On 26 Jul 2023, at 19:32, Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> > But James Perkins has pointed out that such JIRA tracking is kind of >>>> overkill for non-production dependencies (e.g. test and build deps) and I >>>> agree. >>>> >>>> >>>> +1 >>>> >>>> > The other thing I care about a lot is being able to grep the git log >>>> for commits related to a JIRA. That would of course be lost for >>>> non-production upgrades with no JIRA. Oh well. Also though dependabot >>>> wouldn't put our JIRA in its commit messages. But for PRs where we file a >>>> JIRA we can require human edit of the dependabot PR title to reference the >>>> JIRA. That will result in the JIRA appearing in the log via the merge >>>> commit Github generates. That solves the git log use case adequately enough >>>> IMO. >>>> >>>> >>>> As an example, we did experiment with this approach in WildFly Core >>>> with some PR opened by Dependabot: >>>> >>>> https://github.com/wildfly/wildfly-core/pull/4937 >>>> >>>> which resulted in the merge commit: >>>> >>>> >>>> https://github.com/wildfly/wildfly-core/commit/50eafdb9ec87d9d0ad94288e86... >>> >>> >>> +1. >>> >>> People may notice I sometimes edit PR titles a bit before merging, or >>> request title changes during code review. I do this to tweak the merge >>> commit message, usually to add a missing JIRA ref. >>> >>> >>>> >>>> Best regards, >>>> jeff >>>> >>>> -- >>>> Jeff Mesnil >>>> Engineer @ Red Hat JBoss EAP >>>> http://jmesnil.net/ >>>> >>>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> He/Him/His >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His