[wildfly-dev] Re: Turn on dependabot

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