11:25 a.m.
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.
Can we start by just doing this in dependabot.yml:
ignore:
- dependency-name: "*"
update-types:
["version-update:semver-major","version-update:semver-
minor"]
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.
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> 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