CBI/Jenkins Migration FAQ
- 1 Jenkins Migration FAQ
- 1.1 What's happening?
- 1.2 Why are you doing this?
- 1.3 What does that mean for Eclipse projects using the CI infrastructure?
- 1.4 What’s the plan?
- 1.5 Will the new CI infrastructure also support different platforms (e.g. Windows or Mac)?
- 1.6 Will external/remote slaves still be supported?
- 1.7 Will it be possible to trigger jobs on events (like GitHub pull requests)?
- 1.8 Will builds be faster?
- 1.9 Will long-running UI tests be faster?
Jenkins Migration FAQ
Projects hosted at the Eclipse Foundation will soon benefit from a brand new continuous integration (CI) infrastructure. Expected improvements are: resiliency, scalability and nimbleness. We are doing this move with tremendous support from our friends at RedHat with their product 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. Jenkins on 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 Feb 2018, all new projects will get an instance on the new infrastructure instead of a regular JIPP. In the meantime, we will start migrating existing JIPPs by reaching out to projects to tell them when the migration will happen and it fits with their agenda. There is no set timeline, but we aim to ramp up pretty quickly and do the migration as fast as we can.
The migration itself will happen in two times. First, we will create an instance on the new infrastructure with the URL https://ci-staging.eclipse.org/<project_name> and migrate existing build jobs to it. Current instance will stay as is at the URL https://ci.eclipse.org/<project_name>. Once the project will have confirmed that new instance behavior is correct, we will remove the old instance and will make the new instance available at the URL https://ci.eclipse.org/<project_name>. This process should be very little disruptive to contributors and projects users.
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.