On Thu, Jul 27, 2023 at 5:54 PM James Perkins <jperkins(a)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(a)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 do that too. Log grepping is for "I have the JIRA #" use cases, e.g.
where I'm not starting from a file.
I also do a lot of things from the command line that can be done via gui
clicking. Except when I do them from a GUI. :) Pretty much all of these
approaches I do a lot; which I pick really depends on what I'm doing and
what primary tool I'm starting from.
>
> 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