Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CBI/Jenkins Migration FAQ"

< CBI
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= CJE Migration FAQ =
+
= Jenkins Migration FAQ =
 
== What's happening? ==
 
== 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.
+
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? ==
 
== 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.  
+
We need to
 +
* scale up our current JIPP infrastructure, and make it more efficient
 +
* utilize our hardware better and be able to add interim cloud resources when needed
 +
* be able to limit a project's resource consumption and isolate it from other projects
 +
* be able to update Jenkins masters and to install/update Jenkins plugins in batch
 +
* provide more flexibility to projects to let them build their code in containers so that they control the build environment
 +
* have built-in resilience. Jenkins on OpenShift provide this, by leveraging technologies such as Docker and Kubernetes.  
  
 
== What does that mean for Eclipse projects using the CI infrastructure? ==
 
== 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.
+
We don’t expect much disruption, and most projects will only need to change minor things in their build settings. Adjustments will need to be made though, see [https://wiki.eclipse.org/CBI/Jenkins_Migration_FAQ#What_needs_to_be_changed_after_the_migration.3F What needs to be changed after the migration?].
 +
 
 +
== What does [OI2JIRO] stand for in bugs like [https://bugs.eclipse.org/bugs/show_bug.cgi?id=547135 547135]? ==
 +
It means '''O'''ld '''I'''nfrastructure '''2(To)''' '''JIRO'''. It's just a tag that the team is using to easily find all related migration tickets.
 +
 
 +
== What does JIRO mean? ==
 +
See https://github.com/eclipse-cbi/jiro#why-is-it-called-jiro. TL;DR '''J'''enkins '''I'''nstances '''R'''unning [on] '''O'''penShift.
 +
 
 +
== What needs to be changed after the migration? ==
 +
* For build jobs without specific dependencies and UI tests (e.g. a standard Maven/Tycho build) the default jnlp-agent image can and should be used with both freestyle jobs (no special configuration required) or Jenkins pipelines. Basic tools like Ant, Maven, JDK are provided (see https://wiki.eclipse.org/Jenkins#Tools_.28and_locations_on_the_default_JNLP_agent_container.29).
 +
* Build jobs with specific (tool) dependencies (e.g. Node.js, CMake, etc) should try to use corresponding Jenkins plugins first. Please open a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=CI-Jenkins&short_desc=Install%20XXX%20plugin%20for%20JIPP%20YYY Bugzilla issue] to request a plugin installation.
 +
* If a custom tailored build environment is required, you can use a custom docker image and Jenkins pipelines, see https://wiki.eclipse.org/Jenkins#How_do_I_run_my_build_in_a_custom_container.3F for more info. This gives you the most flexible environment, but it requires some knowledge about docker images and Jenkins pipelines.
 +
* For UI tests, see below.
 +
* Publishing to download.eclipse.org requires access via SSH/SCP. We will add the necessary credentials to your JIPP. Please see https://wiki.eclipse.org/Jenkins#How_do_I_deploy_artifacts_to_download.eclipse.org.3F for more info.
 +
* If your project used a RAM disk on the old infra (when in doubt, you probably did not), you will need to adjust your build config accordingly. RAM disks might be added again later on, but this has a very low priority.
 +
 
 +
== How do I run UI-tests on the new infra? ==
 +
For UI tests, there are two scenarios:
 +
* In general, you can use a custom docker image and Jenkins pipelines, see https://wiki.eclipse.org/Jenkins#How_do_I_run_my_build_in_a_custom_container.3F.
 +
* To ease the migration/transition, we provide a '''basic''' UI-test pod template that can be used with freestyle jobs. This image only provides a minimal UI test environment. If your project requires specific dependencies, in most cases, you will need to roll your own.
 +
 
 +
The '''basic''' UI-test pod template  has the label "ui-test" that can be specified in the job configuration under "Restrict where this project can be run".
 +
 
 +
{{important|Migration pod template|In case the ui-test image does not work for you, you can try the "migration" pod template that should be close(r) to the environment on the old infra. '''Please note:''' this should only used during the migration and be replaced with leaner docker images eventually.}}
  
 
== What’s the plan? ==
 
== 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.
+
Starting in February 2019, all new projects will get an instance on the new infrastructure instead of the old infrastructure. In the meantime, we will start migrating existing JIPPs by reaching out to projects to tell them when the migration will happen and see if it fits with their release 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 steps. 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. The current instance on the old infra will stay as is at the URL https://ci.eclipse.org/<project_name>. Once the project will have confirmed that the new instance behavior is correct, we will remove the old instance and will make the new instance available at the original URL https://ci.eclipse.org/<project_name>. This process should cause only slight disruptions for contributors and projects users.
 +
 
 +
== What is happening to instances already hosted on CloudBees Core / Jenkins Enterprise? ==
 +
Those instances (especially EE4J instances) already run inside the cluster and will stay as is at least until we finish the migration of Jenkins instances from the current infrastructure to the new one.
 +
 
 +
== Can we keep the JIPP on the old infra (not all of our builds are working yet on the new infra)? ==
 +
We are moving the JIPPs off the old infra to free up the physical machines (hipp1-10) so we can add the compute power to the cluster. Therefore, we can't keep the old JIPPs around. The projects will have a reasonable amount of time for the migration. We'll support the projects during the migration and try to consider release schedules.
  
 
== Will the new CI infrastructure also support different platforms (e.g. Windows or Mac)? ==
 
== 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.
 
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 [https://github.com/jenkinsci/ghprb-plugin 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.
  
 
[[Category:Releng]] [[Category:Jenkins]]
 
[[Category:Releng]] [[Category:Jenkins]]

Revision as of 10:31, 15 May 2019

Jenkins Migration FAQ

What's happening?

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?

We need to

  • scale up our current JIPP infrastructure, and make it more efficient
  • utilize our hardware better and be able to add interim cloud resources when needed
  • be able to limit a project's resource consumption and isolate it from other projects
  • be able to update Jenkins masters and to install/update Jenkins plugins in batch
  • provide more flexibility to projects to let them build their code in containers so that they control the build environment
  • have built-in resilience. 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 projects will only need to change minor things in their build settings. Adjustments will need to be made though, see What needs to be changed after the migration?.

What does [OI2JIRO] stand for in bugs like 547135?

It means Old Infrastructure 2(To) JIRO. It's just a tag that the team is using to easily find all related migration tickets.

What does JIRO mean?

See https://github.com/eclipse-cbi/jiro#why-is-it-called-jiro. TL;DR Jenkins Instances Running [on] OpenShift.

What needs to be changed after the migration?

  • For build jobs without specific dependencies and UI tests (e.g. a standard Maven/Tycho build) the default jnlp-agent image can and should be used with both freestyle jobs (no special configuration required) or Jenkins pipelines. Basic tools like Ant, Maven, JDK are provided (see https://wiki.eclipse.org/Jenkins#Tools_.28and_locations_on_the_default_JNLP_agent_container.29).
  • Build jobs with specific (tool) dependencies (e.g. Node.js, CMake, etc) should try to use corresponding Jenkins plugins first. Please open a Bugzilla issue to request a plugin installation.
  • If a custom tailored build environment is required, you can use a custom docker image and Jenkins pipelines, see https://wiki.eclipse.org/Jenkins#How_do_I_run_my_build_in_a_custom_container.3F for more info. This gives you the most flexible environment, but it requires some knowledge about docker images and Jenkins pipelines.
  • For UI tests, see below.
  • Publishing to download.eclipse.org requires access via SSH/SCP. We will add the necessary credentials to your JIPP. Please see https://wiki.eclipse.org/Jenkins#How_do_I_deploy_artifacts_to_download.eclipse.org.3F for more info.
  • If your project used a RAM disk on the old infra (when in doubt, you probably did not), you will need to adjust your build config accordingly. RAM disks might be added again later on, but this has a very low priority.

How do I run UI-tests on the new infra?

For UI tests, there are two scenarios:

  • In general, you can use a custom docker image and Jenkins pipelines, see https://wiki.eclipse.org/Jenkins#How_do_I_run_my_build_in_a_custom_container.3F.
  • To ease the migration/transition, we provide a basic UI-test pod template that can be used with freestyle jobs. This image only provides a minimal UI test environment. If your project requires specific dependencies, in most cases, you will need to roll your own.

The basic UI-test pod template has the label "ui-test" that can be specified in the job configuration under "Restrict where this project can be run".

Important.png
Migration pod template
In case the ui-test image does not work for you, you can try the "migration" pod template that should be close(r) to the environment on the old infra. Please note: this should only used during the migration and be replaced with leaner docker images eventually.


What’s the plan?

Starting in February 2019, all new projects will get an instance on the new infrastructure instead of the old infrastructure. In the meantime, we will start migrating existing JIPPs by reaching out to projects to tell them when the migration will happen and see if it fits with their release 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 steps. 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. The current instance on the old infra will stay as is at the URL https://ci.eclipse.org/<project_name>. Once the project will have confirmed that the new instance behavior is correct, we will remove the old instance and will make the new instance available at the original URL https://ci.eclipse.org/<project_name>. This process should cause only slight disruptions for contributors and projects users.

What is happening to instances already hosted on CloudBees Core / Jenkins Enterprise?

Those instances (especially EE4J instances) already run inside the cluster and will stay as is at least until we finish the migration of Jenkins instances from the current infrastructure to the new one.

Can we keep the JIPP on the old infra (not all of our builds are working yet on the new infra)?

We are moving the JIPPs off the old infra to free up the physical machines (hipp1-10) so we can add the compute power to the cluster. Therefore, we can't keep the old JIPPs around. The projects will have a reasonable amount of time for the migration. We'll support the projects during the migration and try to consider release schedules.

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.

Back to the top