Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epsilon-dev] Continuous integration moving to JIRO

Hi Antonio,

Thanks a lot for setting this up!

Cheers

On 21 Aug 2019, at 18:24, Antonio Garcia-Dominguez <agarcdomi@xxxxxxxxx> wrote:

Hi all,

The Eclipse Foundation is now moving away from the traditional one-VM-per-project model for its Jenkins-based continuous integration, and is now moving into JIRO [1]: Jenkins Instances Running on OpenShift. OpenShift is RedHat's enterprise edition of Kubernetes, a Docker container orchestration layer.

Basically, we have now a copy of our old CI environment in the staging server, which will eventually be the real server:


This new environment has broken our old Jenkins interim task, unfortunately. Since jobs run now in Kubernetes "pods" of Docker containers, if we want to have Xvnc (which we need for our UI tests), we need to run our CI tasks on a pod template which uses a Docker image that contains Xvnc. Luckily, this was already thought of by the Eclipse infra team, and they had a ui-test pod template that we could use.

However, to use this custom pod template, we must use a Jenkinsfile to define our Jenkins task. It's pretty much in the same style of a Travis or Gitlab YAML file. Instead of using the (clunky) web UI, the Epsilon repository now has a Jenkinsfile that defines the whole process. There are other changes: the Docker container needs to use SSH/SCP to handle the download area, and the GPG signing has needed some tweaks as well.

This has opened us to quite a lot more functionality: we could even run parallel build stages if we wanted, or use a custom Docker image with specific software. The full Jenkins pipelines docs are in [2]. The new CI task is now here, and I have disabled the old CI task in both ci.eclipse.org and ci-staging.eclipse.org:


It is a new multibranch task, which will run for all branches that have a Jenkinsfile (so far, only master). It will run all tests as usual, and for the master branch, it will also deploy the interim artifacts to the website and to the OSSRH Sonatype Maven repository. Locks are now used to ensure that you do not have two executions touching the website or OSSRH at the same time.

You should be able to use feature branches now, and get CI approval before merging them to the main branch as well. Let me know if you have any questions!

_______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev



Back to the top