[wildfly-dev] Re: Turn on dependabot

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