[wildfly-dev] Re: Turn on dependabot

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 :)

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

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