9:16 p.m.
On Fri, Jul 28, 2023 at 1:04 PM James Perkins <jperkins(a)redhat.com> wrote:
On Fri, Jul 28, 2023 at 10:25 AM Carlo de Wolf <cdewolf(a)redhat.com> wrote:
> Using prospero would make the usage of dependabot obsolete. You would
> only need PRs if there is actually a functional change in the API (usage)
> of a component.
>
I'm not sure I follow. How would this work?
Create an open WildFly channel.[1] An open channel doesn't specify a fixed
version set for every component (somewhat similar to using maven version
ranges.) Components you don't trust for micro updates without human review
you don't make open.
Create CI to test WF against that of builds using that channel instead of
the statically declared versions.
To get humans out of the loop you'd need said CI to completely cover all
test requirements associated with any 'open' components. Otherwise there's
a human promotion step.
[1] https://github.com/wildfly-extras/wildfly-channel
We should do this. But we can't do this today, while if we wanted we could
turn on dependabot today. Or Monday, or whatever soonish day we decide to
do it.
>
> Carlo
>
> On 26-07-2023 19:32, Brian Stansberry 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.
>
> 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...
>
>
> _______________________________________________
> 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