[wildfly-dev] Re: Turn on dependabot

On Thu, Aug 3, 2023 at 2:55 AM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > > On Fri, Jul 28, 2023 at 8:06 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> >> >> >> On Fri, Jul 28, 2023 at 1:03 PM James Perkins <jperkins(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Fri, Jul 28, 2023 at 9:26 AM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> On Thu, Jul 27, 2023 at 5:54 PM James Perkins <jperkins(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Since I've been one that keeps talking about this, it seems I should >>>>> reply here as well :) >>>>> >>>>> In general we could, and really probably should, start with a known >>>>> set of dependencies to upgrade. Otherwise we'll probably see A LOT of >>>>> dependency upgrade PR's. >>>>> >>>> >>>> Can we start by just doing this in dependabot.yml: >>>> >>>> ignore: >>>> - dependency-name: "*" >>>> update-types: ["version-update:semver-major", >>>> "version-update:semver-minor"] >>>> >>> >>> We could, yes. We will likely have a lot of upgrades come in that way. >>> This might be okay, but my initial thought was to list specific >>> dependencies we know to be upgradeable without a JIRA. I'm definitely up >>> for being aggressive if we want though :) >>> >> >> I'll confess to being too lazy to try and figure out which deps to >> allow. :) >> >> >>> >>>> >>>> So we limit things to just the micros. >>>> >>>> Dependabot will only produce 5 open PRs at a time, unless we specify a >>>> different number via dependabot.yml.* So we can process 5 at a time and >>>> even quickly close ones that will require more thought than we want to >>>> spend at that time. The dependency update report that's sent to this list >>>> every week will prevent any we ignore or close from falling into a crack. >>>> >>>> >>>> * Perhaps we should start with a smaller max number and increase it >>>> every day or so until we get to whatever our long-term target is. IOW, >>>> avoid an initial CI-hogging flood. >>>> >>> >>> The CI concerns are definitely valid. I hadn't considered that. >>> >> >> I don't think it's *that* big a deal if our long term target is fairly >> small. Like if we turned it on on a Friday afternoon not near any tagging >> deadline probably no one would even notice the load. >> >> We need to be careful about rebase-strategy though. Having say 5 PRs >> continually rebasing and kicking off CI every time we merge would be bad. >> Probably we should turn it off and use the pull player /retest when we want >> a retest, same as we do with human-created PRs. >> > > +1 this must rebase strategy of GitHub to me feels like the strategy of > how can we make it feel more like SVN - we don't need rebases on our PRs > and if we are concerned about a combo we do one aggregate PR to test > together. > I rebase PR's all the time :) That said, you can still rebase dependabot PR's with a comment of @dependabot rebase. You could use recreate instead as well. The main reason for the rebase though is when a PR has a conflict.

> > >> >> >> https://docs.github.com/en/code-security/dependabot/dependabot-version-up... >> >> >>> >>>> >>>> >>>> >>>>> One thing to note too is that dependabot will create a branch in the >>>>> repository. Anyone doing a fetch locally will get this new branch. Not >>>>> really a huge deal, but something to keep in mind. Locally you might want >>>>> to run git remote prune <your_remote> a little more often if you like to >>>>> keep things clean :) >>>>> >>>> >>>> Thanks for the tip! >>>> >>>> >>>>> >>>>> On Wed, Jul 26, 2023 at 10:33 AM Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> Occasionally we've thought about turning on dependabot for the main >>>>>> WildFly repo, and a couple current discussions (see [1] and [2]) relate to >>>>>> that, so it seems a good time to discuss further and perhaps take action. >>>>>> >>>>>> My main concern with dependabot is it doesn't integrate with JIRA. >>>>>> JIRA is really important to how we're able to keep a handle on a project as >>>>>> complex as WildFly. And I think it's important to track component upgrades >>>>>> in JIRA so our users can keep an eye on what we're providing. Particularly >>>>>> important in the world of ubiquitous CVE scanners. >>>>>> >>>>>> 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. >>>>>> >>>>>> So, how about we turn on dependabot and require a JIRA to be filed >>>>>> and linked to the PR if the proposed upgrade is production code dep? For >>>>>> non-production deps a JIRA would be optional. >>>>>> >>>>>> 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. >>>>>> >>>>> >>>>> TBH I only grep for JIRA's if I have the JIRA I'm trying to find the >>>>> commit for. Short of that, I pretty much just use git blame on the file to >>>>> find out which commit changed a line. But everyone has their own workflow >>>>> and I don't want to push mine on anyone :) >>>>> >>>>> >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> [1] >>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>> [2] >>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>> >>>>>> Best regards, >>>>>> Brian >>>>>> _______________________________________________ >>>>>> 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... >>>>>> >>>>> >>>>> >>>>> -- >>>>> James R. Perkins >>>>> JBoss by Red Hat >>>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Principal Architect, Red Hat JBoss EAP >>>> He/Him/His >>>> >>> >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >> >> >> -- >> 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... >> > -- James R. Perkins JBoss by Red Hat