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 "Hudson-ci/Planning/Better Build Pipeline Orchestration"

(New page: == The problem == One of our major problems with Hudson is the coordination and grouping of multiple jobs. While a lot can be done with the various plug-ins such as join-plugin,parametiz...)
 
m
Line 36: Line 36:
  
 
== Suggested solution  ==
 
== Suggested solution  ==
 
 
  
 
The initial work to solve the problem might be as simple as creating a blocker which is pipeline aware only allowing the job to run if the previous chain of jobs has completed.This way the publish job could have a trigger of every ten minutes, but it would just sit there waiting in ready state until the previous chain has finished.  
 
The initial work to solve the problem might be as simple as creating a blocker which is pipeline aware only allowing the job to run if the previous chain of jobs has completed.This way the publish job could have a trigger of every ten minutes, but it would just sit there waiting in ready state until the previous chain has finished.  
 
 
  
 
A better (long term) solution would be to clean up the triggering and chaining parts, since there is now a multitude of plug-ins trying to complete the functionality and support each other. I would make the passing of parameters a first class options in all triggering mechanism, first class support for diamond shape job chains, and lastly build quality levels.  
 
A better (long term) solution would be to clean up the triggering and chaining parts, since there is now a multitude of plug-ins trying to complete the functionality and support each other. I would make the passing of parameters a first class options in all triggering mechanism, first class support for diamond shape job chains, and lastly build quality levels.  
Line 52: Line 48:
 
#Make the build promotion a integrated feature, leaving the "actions" part of the build-promotion-plugin as plugins. This will also naturally clean up the action list a lot.  
 
#Make the build promotion a integrated feature, leaving the "actions" part of the build-promotion-plugin as plugins. This will also naturally clean up the action list a lot.  
 
#Make the build promotion have a notion of "level" instead of just being a list of named promotion labels. make the log rotator be aware of promotion levels so that we can make it only keep x number of builds of a given promotion and remove all older which did not receive the promotion.
 
#Make the build promotion have a notion of "level" instead of just being a list of named promotion labels. make the log rotator be aware of promotion levels so that we can make it only keep x number of builds of a given promotion and remove all older which did not receive the promotion.
 
 
  
 
== The Job Graph ==
 
== The Job Graph ==

Revision as of 16:02, 4 September 2011

The problem

One of our major problems with Hudson is the coordination and grouping of multiple jobs. While a lot can be done with the various plug-ins such as join-plugin,parametized-trigger-plugin etc. there are still some gaps in the functionality because hudson as a whole has no concept of group of jobs.

In order to illustrate our problem, please consider the following setup.

  1. We have one job which does the actual compile of the project and creates the deployable artifacts.
  2. For each environment we have a series of jobs for deploying and testing the build. See the graph for the job structure, jobs on the same line run in parallel.
  3. The Create job has a timer trigger of once per night in order to recreate the weblogic domains.
  4. The publish job has a timer trigger of once per hour to deploy the newest code.


It is the publish job which is causing the most problems from a job coordination point of view. It does not have a understanding of the chain of jobs which it triggers,so our only option is to set the timer trigger such that there is enough time for the chain of jobs to successfully run. This has two problems.


  1. If the chain of jobs fail early there is no ways for Hudson to see this and trigger a new run of the pipeline (a new run of publish)
  2. If someone manually starts a new publish he has to temporally disable publish so the hourly run does not trigger, otherwise the two series of jobs will step on each others toes.


We have tried to use the block on upstream/downstream but that is not sufficient to solve the problem.The problem with that approach is that the two series of jobs will interleave cauiing unpredictable results. The interleaving problem can for example occur if

  1. "Deploy_B" is running
  2. "Publish" is triggered (queue now has Publish)
  3. "Deploy_B" finishes and triggers "Test" (queue now has Publish,Test)
  4. "Publish" runs and triggers "Publish_A" and "Publish_B" (queue now has Test,Publish_A,Publish_B)
  5. "Test" runs and triggers "Test_A" and "Test_B" (queue now has Publish_A,Publish_B,Test_A,Test_B)


How much interleaving there is depends on the block upstream/downstream settings but I have not been able to fund a combination which results in a predictable "first pipeline finished first" behaviour.


Suggested solution

The initial work to solve the problem might be as simple as creating a blocker which is pipeline aware only allowing the job to run if the previous chain of jobs has completed.This way the publish job could have a trigger of every ten minutes, but it would just sit there waiting in ready state until the previous chain has finished.

A better (long term) solution would be to clean up the triggering and chaining parts, since there is now a multitude of plug-ins trying to complete the functionality and support each other. I would make the passing of parameters a first class options in all triggering mechanism, first class support for diamond shape job chains, and lastly build quality levels.

For the long term I would suggest

  1. Make parameter passing integrated with the core triggering functions, eliminating the need for "paramatetized-trigger-plugin"
  2. Make the join plugin use the new parameter functionality.
  3. make the join plugin support waiting for jobs "further down the chain" instead of as it is now, just the immediate jobs.
  4. Make the build promotion a integrated feature, leaving the "actions" part of the build-promotion-plugin as plugins. This will also naturally clean up the action list a lot.
  5. Make the build promotion have a notion of "level" instead of just being a list of named promotion labels. make the log rotator be aware of promotion levels so that we can make it only keep x number of builds of a given promotion and remove all older which did not receive the promotion.

The Job Graph

Back to the top