[wildfly-dev] Re: Turn on dependabot

On Thu, Aug 3, 2023 at 3:27 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > > > On Thu, Aug 3, 2023 at 2:55 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> >> On Fri, Jul 28, 2023 at 8:06 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> >>> 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. >>> >> >> +1 this must rebase strategy of GitHub to me feels like the strategy of >> how can we make it feel more like SVN - we don't need rebases on our PRs >> and if we are concerned about a combo we do one aggregate PR to test >> together. >> > > I rebase PR's all the time :) That said, you can still rebase dependabot > PR's with a comment of @dependabot rebase. You could use recreate instead > as well. The main reason for the rebase though is when a PR has a conflict. > Yeah for merge conflicts rebases are often the best, it is more the GitHub options of deliberately updating commit history I am commenting on.

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