On 15/04/2022 00:20, Robert Varga wrote:
Just to qualify this end-to-end in terms of the NETCONF/RESTCONF pass-through case.- Leverage K8s to do multi-application and scale testing.I think int/packaging some overhaul here. At the end of the day, the first use case we need to have is a Docker (or whatever, I don't care) based on netconf.git/static being packaged as part of netconf-maven-merge job. I have no idea what we need to make that happen, though.
netconf-maven-stage-master should produce a container containing the use-case, using whatever runtime (dynamic Karaf, static Karaf, Guice, Dagger, it does not matter.
netconf.git-hosted CSIT should combine that with a Helm chart on the LFIT-K8S-implementation-du-jour. Run netconf.git-hosted CSIT on that. ~80% of int/test infra is not in the picture.
If it passes, netconf-maven-release-merge is good to go and should run automatically (and lock the branch, bump versions, tag the release, all that jazz). No committer intervention necessary.
Once that completes, downstream projects should realize "hey, there is an upgraded upstream, perhaps I need to release with what I have", go through exactly the same process, rinse&repeat until you hit an autorelease project.
And then the question arises: why do we have autorelease and cannot just publish int/dist release based on this pipeline to Maven Central? :)
So ... what is up for getting their hands dirty?