[wildfly-dev] Re: Turn on dependabot

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.

> > > 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... >