CBI/Jenkins Migration FAQ

CJE Migration FAQ

What's happening?

Projects hosted at the Eclipse Foundation will soon benefit from a brand new enterprise-grade continuous integration (CI) infrastructure. Expected improvements are: resiliency, scalability and nimbleness. We are doing this move with tremendous support from our friends at CloudBees and RedHat with their respective products Jenkins Enterprise (CJE) and OpenShift Container Platform.

Why are you doing this?

To scale up our current JIPP infrastructure, and make it more efficient. We need to better use our hardware and be able to add interim cloud resources when needed. We need something where each project resource consumption is isolated from each other. We need to be able to update Jenkins masters and to install/update Jenkins plugins in batch. We need to provide more flexibility to projects to let them build their code in containers so that they control the build environment. We need a solution where resilience is built-in. CJE and OpenShift provide this, by leveraging technologies such as Docker and Kubernetes.

What does that mean for Eclipse projects using the CI infrastructure?

We don’t expect much disruption, and most of projects won’t need to change anything to their build settings.

What’s the plan?

Starting in June 2018, all new projects will get a CloudBees Jenkins Enterprise JIPP instead of a regular JIPP. Soon after, we will start migrating existing JIPPs by calling for volunteer guinea pigs. Once this is done and we get confident in the process, we will gradually ramp up the migration and move all remaining projects over to CJE. There is no set timeline, but we aim to move most projects to CJE before the end of the year.

Will the new CI infrastructure also support different platforms (e.g. Windows or Mac)?

Yes, we will try to integrate existing and new (cloud hosted) Windows and Mac machines.

Will external/remote slaves still be supported?

Yes, they will be supported.

Will it be possible to trigger jobs on events (like GitHub pull requests)?

This is already working in the current environment with the help of the GitHub pull request plugin and will continue to be working on the new infrastructure.

Will builds be faster?

As mentioned above, we are aiming to better utilize our existing hardware, add additional (cloud based) resources and isolate resource consumption. This should improve the build times in general.

Will long-running UI tests be faster?

More flexible build agents should speed things up. We will also have better monitoring to identify potential bottle-necks. Jenkins Pipelines also make it easier to set up tests in parallel.