I don’t have enough knowledge on this to answer your question, Gary. But my hope is we can get this fix so Beijing delivers tagged code as well.
Thanks, Alexis > On Feb 28, 2018, at 3:32 PM, Gary Wu <gary.i...@huawei.com> wrote: > > 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
