Usually the maven release plugin is used for this, which would:
· Checkout SNAPSHOT version poms, e.g. “1.1-SNAPSHOT” · Update poms to release version, e.g. “1.1” · Build and run all tests · Commit release version poms into git repo · Tag this “release version” commit in git · Update poms to next SNAPSHOT version, e.g. “1.2-SNAPSHOT” · Commit new SNAPSHOT version poms into git repo However, this conflicts with our use of staging/RC builds since we obviously don’t want to commit pom changes for every RC build. To work with staging/RC builds, the ODL method of saving git bundles for later tagging seems like it would work fine. Are there any downsides to this approach? Thanks, Gary From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët Sent: Wednesday, February 28, 2018 11:07 AM To: t...@lists.onap.org; onap-discuss <onap-disc...@lists.onap.org> Subject: Re: [onap-tsc] Release management process is broken Does anyone has any input on the same? I think it is *critical* that we can deliver tagged artifacts (whether maven, docker *and code*) for each of our release. Most importantly, for Beijing coming in a few weeks. We had a discussion last week on the #lf-releng channel, and it seems the issue is identified. See raw discussion snippet bellow tykeal hmm.... I think I may know what the problem here is. The ONAP releases are done using the maven version plugin. The release jobs take the current version that gets checked out and then for the release job the version plugin is run to drop the SNAPSHOT name and then produce the artifacts zxiiro adetalhouet_: looks like you got all the points to me. tykeal as such gerrit doesn't have any of the released versions actually stored but the target tag points to the version that was checked out to produce the release artifacts zxiiro tykeal: maven version plugin should take care of removing the snapshot AND git tagging though if I recall. tykeal zxiiro: it's not being used to do the tagging zxiiro :/ zxiiro looks like they are missing the step we do in ODL where we produce git.bundles and store it in the log server for tagging at a later date. tykeal ONAP release process at present is basically the following: tykeal daily jobs produce RC builds tykeal a request is made to release the builds staging repo produced by job XYZ tykeal RE looks up the staging repo from the job output tykeal signs the artifacts and releases them tykeal looks up the git sha that was checked out by the job and tags it zxiiro ya that's not right. they need to get the git.bundle and Jenkins should be producing it by creating a commit on the pom.xmls that it modified before the build. tykeal zxiiro: yes, they're missing that step because ONAP isn't using the release jobs that ODL created because global-jjb didn't exist when they implemented and they didn't want to copy the work that ODL had already done zxiiro even if we drop the SNAPSHOTS and tag from the same base commit, that produces a new sha so while it looks the same it is not identical. Which is why it's so important to save the git.bundles. * AlexAvadanii has quit (Ping timeout: 256 seconds) * CristinaPauna has quit (Ping timeout: 248 seconds) tykeal @zxiiro: I'm not saying that they're producing an updated commit, they're are literally tagging the commit that Jenkins checked out, not one with a modified pom Alexis On Feb 23, 2018, at 10:58 AM, Alexis de Talhouët <adetalhoue...@gmail.com<mailto:adetalhoue...@gmail.com>> wrote: Hello TSC, Release management team, I just found out our release process is somewhat broken. We should never be tagging snapshot commits as releases, and tags in projects relates to SNAPSHOT. Even more, they are multiple tags pointing to the same SNAPSHOT. I can see they are released artifacts in Nexus, but there is no corresponding code for it, although I would have expect the tag to have the code at the very specific commit used for the release. This is a major concern, as this means it’s impossible for downstream users to consume and develop their own stuff on released ONAP code (as it doesn’t exist). It’s also impossible to debug issues as we don’t have the exact version of the code we’re running. Can this topic be added at the TSC next week? Alexis
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
