On Thu, Jul 27, 2023 at 11:54 PM James Perkins <jperkins@redhat.com> 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.

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@redhat.com> 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 :)

I try to be a bit more positive than the rest of you and use "git annotate" 😉 but yeah the Jira issue in the merge commit would likely not show there.  However searching git log if you have the dependabot commit it will be quite easy to find the merge commit so not that far removed.
 
 
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/6UDLHXNSMPARNH6UCPSLWPOOCZP3VDIK/


--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/UPOCS4WL7MI5RLAKKQWR7VRUTGUMN55K/