Full PRO release
| 3-4 weeks before the Release
|| Write Release announcement Email (see template), including information on when the Release branches should be there and how to create them.
| 3-5 days before the Release
|| Create Wiki page with Release Order graph, see below
| 1-2 days before Release
|| Write a reminder Email, that all branches must be there, which day which time
| 0 + x
| 0 + xx
|| After Rollout is performed, LSA and BSS are up and running and Modellers have imported the Physics Model, write the Release Email (see template)
Before the Release
Create Wiki Page with Release Graph
On our Releasepage
, create a new Subpage for the upcoming Release.
For creating the release graph, we first checkout the master branches of all involved projects.
To do so, we first edit the checkout reactor accordingly and check if the list of projects needs to be adapted.
gedit /common/usr/lsa/bin/mkws/checkout.reactor &
Then we perform the checkout of the master branche of those projects:
/common/usr/lsa/bin/mkws/checkout.reactor --ssh --flat -b master -p /common/scratch/cscoap/$USER/master/
Once all projects are checked out, the graph can be created using:
The graphs will reside in the target folder of the reactor.
Copy the contents of the /target/ ReleaseOrderGraph
.dot to the Release Wiki page. It is not yet a working graph, but some tags must be placed before it:
<span class='WYSIWYG_COLOR' style='background-color: #ffff00; color: yellow;'>______</span> = release branch is already created
<span class='WYSIWYG_COLOR' style='background-color: lightgreen; color: lightgreen;'>______</span> = project is released
<span class='WYSIWYG_COLOR' style='background-color: lightgrey; color: lightgrey;'>______</span> = project is obsolete
<graphviz type="svg" style="width:100%;height:auto" inline="true">
CONTENT OF ReleaseOrderGraph.dot HERE
If the Wikipage just shows errors, please check for Umlaute / special characters in Release Engineer names. Also check that you copied the above section correctly and placed it before the graph contents.
Performing the Release
Checkout all projects
Clone all projects using the R16 Release branch:
/common/usr/lsa/bin/mkws/checkout.reactor --ssh --flat -b R16 -p /common/scratch/cscoap/$USER/release/
You can perform the script many times, it skips already cloned repositories and prints those, that are still missing.
Create missing Release Branches yourself (optional)
If you need to create the Release branch for a project yourself, you can do so by using the normal branching command in the master clone and calling the checkout.reactor for the release afterwards.
Release of parents
csco-parent* are released like any other artifact.
However, the acoapp-cern-bom needs manual interaction
please call the LSA-Team here.
If the parents need to be released in advance, please refert to this extra Wikipage
for this procedure.
Note that the parents have to be removed from the release-reactor in this case.
Release of all other projects
With the reactor, many or even all projects can be released at once. However it can also be beneficial to release first lower level common-library Projects, than LSA, then applications. This can be achieved by passing the
argument specifing the projects to release to the reactor release script.
Doing so, you have to ensure manually, that all needed dependencies are already released or within the listed projects, otherwise your release will fail due to missing dependencies or even might include older dependencies.
For 1..n projects, perform the release
Check the pom.xml for each project
It is necessary to check each pom.xml file before the release.
Follwing pitfalls exist and must be corrected before the release:
- please make sure, that developers and roles are still correct, remove any Umlaute here !!!! e.g. Müller -> Mueller as otherwise the Release Order Graph will not be working
- cleanup dependencies:
- remove direct dependencies that anyway come through others, might be a leftover from a quick bugfix
- remove dependencies, that are commented out, especially those with -SNAPSHOT in the name as they cause problems in the release process
- check that there are no fixed older pro-versions defined, e.g. pointing to 15.0.0 (as only -SNAPSHOTS will be increased to the latest pro release version number). Those should point to the lastest master SNAPSHOT version instead.
In Email die Release preparation steps verlinken, dieses hier eher löschen.(?)
git clone https://git.acc.gsi.de/schaller/scripts
../scripts/mvn/mvn_reactor_release -rv 16.0.0 -dv 16.0.1-SNAPSHOT
Problems during the Release and Recovery
Release cannot be performed at all e.g. due to missing dependencies or Javadoc errors
No recovery needed. Just start the release all over again (providing the
flag to the reactor release script)
Release successful, Tag screwed up
While the release seems successful, the file does not exist in Jenkins (typically fails in upstream projects) and the corresponding pom.xml file of the created tag is screwed up, i.e. it contains SNAPSHOT versions. (Cause of this error is currently not known). In this case we need to manually delete the tag, reset in Git history to the point before the release and run the complete release process again.
[jfitzek@asl742 cscoap-common-units-ui]$ git tag -d cscoap-common-units-ui-16.0.0
[jfitzek@asl742 cscoap-common-units-ui]$ git push origin :refs/tags/cscoap-common-units-ui-16.0.0
[jfitzek@asl742 cscoap-common-units-ui]$ git hist -n 5
[jfitzek@asl742 cscoap-common-units-ui]$ git reset --hard deb64b1 (use the commit Id before the release started)
HEAD is now at deb64b1 JF: pom cleanup before release
[jfitzek@asl742 cscoap-common-units-ui]$ git push -f
Release successful, Tag looks correct, no file in Nexus
While the release seems successful, the file does not exist in Nexus (typically fails in upstream projects). (Cause of this error is currently not known).
In this case, we can checkout the tag and just perform mvn deploy to upload it to jenkins:
[jfitzek@asl742 parammodi-app]$ git reset --hard parammodi-app-16.0.0
[jfitzek@asl742 parammodi-app]$ mvn deploy
Release successful, Tag correct, file in Nexus, but site deploy failed
If only the site deploy failed, you can easily repeat it by using
[jfitzek@asl742 bss-patterngroup-config]$ git reset --hard bss-patterngroup-config-16.0.0
[jfitzek@asl742 bss-patterngroup-config]$ mvn site-deploy -Prelease
However if the site deploy failed due to a lack of permissions, than check if you have done the step to rename the old site directory for the old version? If not, please do so now !!! and repeat any site deploys for downstream projects..
Release-Voraussetzungen: altes Site Verzeichnis verschieben
After the Release
Checkin any changes to cscoap-reactor/pom.xml. If you removed the pom.xml temporarily from Git change tracking, than remember to add it first again:
[jfitzek@asl742 cscoap-reactor]$ git update-index --no-assume-unchanged pom.xml
wenn von INT gebrancht, sollte das Releasescript auch RC-INT ersetzen können zusätzlich
- 19 Nov 2020