Hi Andy, Thanks for your feedback. I would like to do a trial run of this process with oparent and document the instructions.
To confirm, is the preferred way to do a staging build via the "-release-version-java-daily" jobs? Do we currently have any documentation on how to setup/use the staging build jobs? For example, I think it requires a version.properties file to be defined in the repo; not sure if there are other requirements. For the GPG signed tag, do we have any recommended instructions for the project committers/PTLs to do so themselves, or should we assume that LFRE will take care of this for the time being? Thanks, Gary -----Original Message----- From: Andrew Grimberg via RT [mailto:onap-helpd...@rt.linuxfoundation.org] Sent: Wednesday, August 16, 2017 11:59 AM To: Gary Wu <gary.i...@huawei.com> Cc: onap-discuss@lists.onap.org Subject: Re: [ONAP Helpdesk #44125] Independent project artifact release process Greetings Gary, On 08/16/2017 11:34 AM, Gary Wu via RT wrote: > Resending since I didn't get a ticket number back for some reason last time. Not certain why you didn't. The original ticket, which I've merged this into is 44125 > From: Gary Wu > Sent: Wednesday, August 09, 2017 12:37 PM > To: 'helpd...@onap.org' <helpd...@onap.org> > Cc: onap-discuss@lists.onap.org > Subject: [integration] Independent project artifact release process > > Hi helpdesk, > > ONAP is moving toward a model where each project/repo will be > releasing its own artifacts and versions, and cross-repo dependencies > are on release artifacts only (i.e. no SNAPSHOT/staging dependencies). > Integration will be piloting this with oparent and clamp repos to work > out all the kinks. > > To that end, we will need a clear process for individual projects to > version bump and release their own artifacts. > > ONAP currently has Jenkins job definitions that will deploy release > artifact candidates to staging. What seems to be missing is a way for > a project to pick a candidate from staging and formally release it > into the Releases repo. Does this process exist? If so, can you point > me to some documentation on how this process works? If not, can you > share your thoughts on how we can best implement this last step? The closest we currently have is the process that OpenDaylight has been operating with for their odlparent project which as of the current release cycle has broken off to doing independent releases of it's one. In fact during the Nitrogen cycle it's already had at least 4 releases that I'm aware of! The current process that has been in use in ODL by odlparent is detailed in the lead mail in this [0] mailing list thread. LF is working on ways that the we can grant more of the process control to the projects themselves but we don't currently have everything needed for it just yet. To get the heart of your request the current way for an ONAP project to formally do a release at present would be as follows: 1) A staging build has happened. In the job logs there will be a notice as to what the staging repository that was created is. This needs to be captured by a project committer / PTL that will be requesting a release 2) Any testing that needs to be performed against the artifacts is performed. 3) A helpdesk ticket is opened requesting that LF Release Engineering perform a signing and release operation on the target staging repository 4) LFRE will pull the artifacts, GPG sign them, push a secondary staging repository with the signatures and then perform a release operation inside nexus which will cause it to transition both the requested staging repository and the signature repository to copy into the releases repository and then delete the staging repositories. 5) A GPG signed tag needs to be placed on the commit by either LFRE or preferably the PTL or a committer of the project with the release version For docker images, we don't currently have as much automated tooling in place but the basic flow is: 1) Identify the STAGING docker slice that is to be released 2) Open a ticket with LF to release the specific docker 3) LFRE will pull the docker image and retag it into the nexus docker releases repository and push 4) The image should also then be pushed to dockerhub Eventually, this will all get fully automated in some fashion with the correct checks and balances in place for restricting who can do what. Once we have a good automation flow in place then it will probably be a matter of an authorized party submitting a gerrit change to a special repository / specially formatted comment to trigger Jenkins to perform operations on behalf of folks. -Andy- [0] https://lists.opendaylight.org/pipermail/dev/2017-August/003990.html -- Andrew J Grimberg Lead, IT Release Engineering The Linux Foundation _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
