Release Steps Jobs On Jenkins

The Release Steps jobs on Jenkins are an attempt to break the creation of release artifacts into several smaller steps and only require that one computer (the Jenkins server) be configured to create the release artifacts. The Release Manager must still be configured to VERIFY that the release artifacts are correct.

Historically, only one person has been able to run the releasecandidate.xml scripts successfully. Others reported issues with network connections and unreliable upload and download of artifacts and dependencies. So, having one machine configured that we know will work should help others become release managers and not have to figure out how to configure their machines and networks.

Verification

The purpose of verification is to convince the RM that it is safe to GPG sign the artifacts created on a shared server like the CI Server. This is done by having the release scripts create JARs and SWCs that are binary identical no matter what computer builds the binary (Mac or Win). This assumes that the RM has the same versions of Java and Ant (for sure) and probably Maven.

The Ant source package is verified in a slightly different way. The verification script clones the tags from the 3 repos onto the RM's computer and builds its own source package. The result will not binary match what the CI server generated because making it match would require running a Maven plug-in and we don't want to require that everyone who wants to build a release package (for nightly builds and other reasons) have both Ant and Maven. We only want to require that of RMs for now. So the verification script runs the Maven plugin on both the CI-generated Ant source package and the RM's generated source package and verifies that they are binary identical.

Security

One reason for so many release steps is that we do not want to store any credentials on the CI Server, so every time there is something to be pushed to Git, the release step has to end and request that the RM login to the CI Server and enter their Github username and password.

Similarly, when GPG signatures are required, the RM must download the artifacts to be signed and do the signing locally. The RM's keys should never be transferred/copied to the CI Server

Job Details

The various jobs all end by sending an email to dev@royale.a.o if successful. If the emails are not clear, please improve them. The template for the emails are sort of hidden in a Jenkins job configuration. Go to "Post-Build Actions" at the bottom of the config page, then choose "Advanced Setting", then find the "Success" email and choose "Advanced".

Release Step 001

This step creates the release branch for royale-compiler from the develop branch using Maven. Maven updates the develop branch to the next version number which is why it needs a "git push". Then other release steps will modify the release branch so the email at the end of this step requests that the RM run two git commands to set up remote origin tracking of the release branch.

Future Improvements

Uploading failures

The current steps still require that the RM be able to upload a lot of artifacts to the Nexus Staging Repository and Apache's dist.apache.org. If folks still have issues with uploads, we can alter the scripts to upload only the PGP signature files from the RM's computer and upload the other artifacts from the CI Server

However, it should be possible to "retry" the uploads by re-running the upload steps locally.