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

[Olblak]

> 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.

This simplify the version management.
But I am still confused by the current versioning strategy and release target.
For instance, https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-war/2.121/, does it mean that 2.121 is the weekly release and 2.121.1 is the lts version.

I could move the current Jenkinsfile prototype to a shared library and call the same script from jenkinsci/jenkins and jenkins-cert/jenkins. 
We could use maven profile to apply different behaviors

Something like:

when Artifacts need to signed:
    Run from trusted.ci
    when repo == "jenkinsci/jenkins" && branch contain stable' publish lts
        Upload distribution (Debian,Redhat,...) packages on '*-stable' blob storage like https://github.com/jenkins-infra/azure/blob/f01ce2aa7d1829a97aec0d97cbcbb7353cee53c4/plans/releases-storage.tf#L37
        Upload artifacts on https://repo.jenkins-ci.org/release/
        Update docker image
        mvn provile == release
    when repo == "jenkinsci/jenkins" && branch = master, release weekly version
        https://repo.jenkins-ci.org/release/
        Upload distribution packages on '*' blob storage like https://github.com/jenkins-infra/azure/blob/f01ce2aa7d1829a97aec0d97cbcbb7353cee53c4/plans/releases-storage.tf#L31
        Update docker image
        mvn provile == release

Artifacts don't need to be signed:
  Run from anywhere else.
  when repo == 'jenkins-cert/jenkins"
       Upload artifacts on https://repo.jenkins-ci.org/cert-snapshots/
       Do not create distribution packages
       mvn profile == jenkins-cert

On Fri, Jul 27, 2018, at 10:25 PM, Daniel Beck wrote:
> 
> > 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.
>