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