[RELENG-60] Provide tools and documentation to allow projects to release outside a simultaneous release Created: 15/Jun/17  Updated: 04/Nov/19  Resolved: 04/Nov/19

Status: Closed
Project: releng
Component/s: Autorelease
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Colin Dixon Assignee: Thanh Ha (zxiiro)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 8698

 Description   

As it stands there is no good way for a project to release outside of a simultaneous release. Going forward, we should provide tools (JJB templates?) to complete a release and publish it to a staging repository where it can be promoted to actually released (by LF staff or should projects have that permission too?). Also, we need to have tools or very good documentation to explain how to then do reasonable version bumps to prevent conflicts in SNAPSHOT repos on nexus.

As part of that, release jobs (and autorelease) should produce csv files of all released artifacts with groupId, artifactId, and version which can be used for projects to target that (auto)release job's run for their dependencies.

Beyond that, we probably also want tools to allow for a project to target a set of (auto)release jobs output as their dependencies. This should allow for a project to become "compatible with" a given release after the fact. For example to be compatible with a run of autorelease despite not participating in that simultaneous release.

This last part probably amounts to a tool that takes a list of csv files and the replaces any versions for those artifacts in pom.xml and features.xml files in a subdirectory with those in the csv files and then makes sure that the only SNAPHSHOT version files are for the right groupId.

 Comments   
Comment by Colin Dixon [ 16/Jun/17 ]

General plan from notes at the Nitrogen DDF:

1.) Make autorelease produce at versions.csv file
2.) You need a script which takes the csv file and replaces all <version> tags with the right one from lookup in csv

  • Is it enough to just look for <artifactId> and <groupId> and <version> at the same level, replace the version
  • Optionally ignore your own groupId and subtree
  • Optionally sanity check of things that are still SNAPSHOT are only your own groupIds
    3.) Have a release job which removes your -SNAPSHOT and then publishes to staging repo
  • Optionally publish a new versions.csv file for this release
  • Copy most config and things from autorelease
    4.) Bump versions and set back snapshot
    5.) Who promotes the staging repository?
  • Could the PTL get the permissions
  • Do we want two release repos: one for Simultaneous Release another for off-cycle release
    6.) Instructions for repo:add and feature:install
    7.) Do we allow CSIT for projects that require repo:add? Add that command to robot?

Note, 3-4 might be be handled by the maven release plugin.

Comment by Thanh Ha (zxiiro) [ 19/Jun/17 ]

(In reply to Colin Dixon from comment #1)

1) Is now possible due to https://git.opendaylight.org/gerrit/58124

2) Still needs to be built.

3 & 4) Is handled by `lftools version` script although it does not differentiate between groupIds although in theory if you're dependencies are already released then you shouldn't have any SNAPSHOTS outside of your own project anyway.

5) Currently only HelpDesk can handle it however we will need to engage with LFIT if they'd be willing to allow project committers to promote their own staging repos.

6 & 7) I'm not sure about.

Comment by Thanh Ha (zxiiro) [ 04/Nov/19 ]

LF has released a set of global-jjb jobs which makes this possible now.

Generated at Wed Feb 07 20:37:24 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.