[Jenkins-infra] [INFRA-910] Automating release of Jenkins

Daniel Beck ml at beckweb.net
Fri Jul 27 20:25:46 UTC 2018

> On 27. Jul 2018, at 21:54, Olblak <me at olblak.com> wrote:
> Does it mean that master correspond to weekly and stable-* to lts release?

Except for security releases, yes. (Plus there could be rare emergency releases.)

> Does the branch name format have a meaning?

Convention, but Oliver has some scripts to help with LTS handling, so it's probably fairly locked in by now.

> Does it make sense to use the branch name to define the kind of release?
> If the branch is <mavenProfile>-<version>, mvn command would be " mvn -P <mavenProfile> -Dtag=<version> release:prepare

We stage from security-stable-2.xxx in the security project due to how work on security fixes is organized (you should have access to the docs at https://github.com/jenkinsci-cert/jenkins/wiki/ ). Not unchangeable, but a plan going forward would be nice.

> I noticed that maven increment the version when mvn release:perform is called, how does that works if:
> You run mvn release:perform from master current version 2.132 and then you create a branch stable-2.13X and run release:perform from there.
> Is the version be incremented two times? 2.132 and then 2.133

After branch creation, we run `mvn versions:set` or equivalent (we already do this today) and commit the result. As long as releases from non-master branches aren't automatic, we can easily handle this in the process.


Regarding the Jenkinsfile you link to: The best build scripts are done in shell scripts and similar as much as possible, and only glued together as needed by Pipeline. This way, we retain the ability to run (parts of) the build locally without having a properly set up Jenkins.

I'm sure this has nice visualization with the stages and everything, but that benefit is easily outweighed the first time I need to run this locally, but can't.

More information about the Jenkins-infra mailing list