Skip to end of metadata
Go to start of metadata

Ties the parent build of a multi-configuration project to a node.

Plugin Information

View Matrix Tie Parent on the plugin site for more information.

As JENKINS-7825 is fixed in Jenkins 1.521, this plugin is now deprecated. Please look under the "advanced" option of the matrix project configuration to tie the matrix parent to a label/slave.

Simple groovy script to perform the migration. Users are encouraged to backup first.

j = Jenkins.instance;
 
jobs = j.items.grep { it instanceof hudson.matrix.MatrixProject }
 
jobs.grep {
  wrapper(it) != null
}.each {
  println "${it.fullName}"
  def wrpr = wrapper(it)
  println "\t${wrpr.labelName}"
  
  it.setAssignedLabel(j.getLabel(wrpr.labelName));
  it.getBuildWrappersList().remove(wrpr);
  it.save();
}.size();
 
def wrapper(mp) {
  return mp.getBuildWrappersList().get(matrixtieparent.BuildWrapperMtp.class)
}

Usage

Multi-Configuration projects always run one parent build job. The parent build verifies source control checkout operations, then monitors the execution of child jobs created to satisfy the Configuration Matrix.

Sometimes the parent build must run on some computers, but not others. This may be due to constraints such as a lack of source control or other software on a computer, file permission issues, etc.

Restrict where the parent build runs by selecting a specific computer's node name. Or, use a label to restrict the parent build to run only on computers marked with that label.

Limitations

  • System property hudson.model.Hudson.flyweightSupport must be set to true. This is Jenkins' default setting since v1.337.

Changelog

Version 1.1 - August 23, 2010

  • Requires Hudson ver. 1.373 or newer.
  • Fix exception caused by Hudson core changes introduced in v1.372. Fixed for v1.373 and newer. (Don't use v1.372)

Version 1.0 - June 8, 2010

  • Works with Hudson versions 1.361 thru 1.371
  • Initial release.

21 Comments

  1. Unknown User (v-vanwynsberghe@scarlet.be)

    All,

    When the Matrix Tie Parent Plugin will be available for download ?

    Is there a way to workaround the problem with the Hudson version 1.353 ?

    Regards,

    Vincent

    1. I'm afraid that I don't know when this will be available.  I've just requested that the maintainers of the Hudson core evaluate the JENKINS-6180 patch for acceptance.

      Note that if the change to core is accepted, then I can release the plugin; however, you will have to upgrade your version of Hudson to something newer than v1.353.

  2. Unknown User (v-vanwynsberghe@scarlet.be)

    with the version 1.353, how can I force the parent build of a multi-platform project on a dedicated node ?

  3. Unknown User (axel.heider@gi-de.com)

    This is really what I have been looking for. Thanks.

    Could you make the GUI look like in "Build on multiple nodes", ie having a tree-view with "nodes" and "labels" on the first level. This is easier as the plain list with everything.

  4. Unknown User (alex.lavoro.propio@gmail.com)

    Couriously, at first glimpse I thought that this is very useful, but I cannot come up with a scenario which I'd want to tie the parent build in a specific node ? You said:

    Sometimes the parent build must run on some computers, but not others. This may be due to constraints such as a lack of source control or other software on a computer, file permission issues, etc.

    but the children builds, which are not tied to the same specific node, will have to check out the same source from the same version control as the parent build, won't they ?

    1. What may not be obvious, is Hudson's strategy to run the parent build.

      Suppose you have hudson.model.Hudson.flyweightSupport set to true (the default) and you have your slaves configured for "Utilize this slave as much as possible".  Then Hudson may run the parent build on *any* of your slaves.

      Hudson will not constrain itself to one of the "Individual nodes" or "Labels" that you selected in your Configuration Matrix. Hudson uses a hash of the name of your job to determine the slave that runs the parent build.  So, you may get lucky and the parent build may run on a slave that you can live with.  Or, you may get unlucky and Hudson will choose your one-off Windows slave that only runs StarTeam for version control (oops).

    2. Unknown User (axel.heider@gi-de.com)

      Batch-Tasks for a matrix-job run on the parent node. With a random node beeing used, a Windows batch task on a linux machine will fail.

  5. Unknown User (dbubovych@gmail.com)

    Is it possible to extend this plugin to use with a free-style software project? Such project can also be run in distributed mode. In my case SCM is available only on master node.

    1. I think you may want a feature that is native to free-style software projects.  For Hudson v1.372 and newer, look for "Restrict where this project can be run" option.  For earlier Hudson versions, it was called something like "Tie this project to a node".

      1. Unknown User (dbubovych@gmail.com)

        I'm going to use "Tie this project to a node" to delegate builds to remote hosts. That allows to discharge central server and make rebuild of the whole projects group much faster. The problem is that remote hosts are located in a different ClearCase regions, and replication happens with time interval of a hours. So SCM polling, and actually all other ClearCase operations could not be run on slaves (and by default they run on slaves). I found that multi-configuration project and Tie Parent plugin solves my problem with attaching parent build to master node. The thing that confuse me is that I do not need multi-configuration project, there is only one build step that must be executed on one host. Multi-configuration project adds some complexity to BS configuration, build results and logs navigation on dashboard becomes not so obvious as with Free-Style project. It would be nice to manage with Free-Style project. Does Tie Parent plugin could be run with it? Also, I wonder if there any documentation on what is parent build job. May be it could be configured explicitly?

        1. Sami Tikka has some good recommendations in his reply to a similar question about "Concurrent projects with downstream projects ".  It sounds like you may want to use a single, free-style project that builds, "Archives the artifacts",  "Record fingerprints of files to track usage", then triggers a downstream project.  Your downstream project might then be a multi-configuration project where each child job gets the artifact(s) from the free-style project, then begins its work.

  6. Unknown User (michael haertl)

    Where exactly am I supposed to see the "Build Environment" section and the "Tie parent build to a node" checkbox ? Somehow i cannot find it (i already restarted hudson with v1.381). Should I re-create my project(s) ?

    1. Unknown User (michael haertl)

      Somehow I missed to install the plugin first (I guess I clicked too much) ;-) Sorry for not looking closely enough, now it shows up on the project configure page.

  7. This doesn't seem to be working for me in Jenkins 1.456. I have several jobs that are tied to different parent nodes, and none of the restrictions are being honored.

    I re-opened this issue as well, because it also seems like this is basic functionality, and should not require a plugin...

    https://issues.jenkins-ci.org/browse/JENKINS-7683

    1. OK, I'll start looking at this...

      I defined a simple job with a "User Defined Axis" and "Slaves" matrix.  When I tied the parent build to a node, the request was honored.  I tried changing the node and it continued to work.  

      Do you have a more complicated job configuration where you see this problem?

  8. Hi,

    I wonder if there's a way to configure a custom parent build, say to have the parent build run a specific script? It's like a "pre build" running on the parent build job. The use case here is to have the parent build run some planning jobs to to determine what each slave needs to do. 

    This can also be achieved by triggering another job, I'd like to have everything run in a single matrix job which is more clean.

    Thanks,
    Jimmy

    1. Take a look at the "Execute touchstone builds first" feature. It let's you split your collection of child jobs into two groups. The first group (touchstone builds) all run in parallel to completion. If and only if all those jobs SUCCEED, then your main/normal/other group of child jobs start all running in parallel.

      So, you may want to configure your planning jobs to belong to the touchstone group. When complete, a planning job can save an artifact with what-each-slave-needs-to-do logic. Then, the other jobs can wget the artifact from the touchstone build(s) to figure out what to do. Downloading the artifact is reliable because the BUILD_NUMBER environment variables are all synchronized amongst all the jobs in the matrix.

      1. Hi Ken,

        Thanks for your quick response. This sounds very promising. However, when other jobs wget the artifact, how do they know the hostname of the touchstone builds to download from? 

        Are the artifacts stored in the master node (uploaded from slaves to master)? If that's the case this won't be an issue. 

        Also, is there a way to only have the touchstone build produce the artifacts? I don't need to have all the matrix jobs generate the artifacts.

        Thanks,
        Jimmy

        1. Jenkins URL's to download artifacts are stable.  For example, here's how I get a "touchstone" build artifact on one of my matrix builds (on Linux):

          • wget -q "${JENKINS_URL}job/mc-personal-precheckin/RUN=.build-P100,label=mc-build-pool/${BUILD_NUMBER}/artifact/P100B051-01.bin"

          I'm sure you'll be able to figure out the URL that you will need for your download.  And yes, the artifacts are all stored on the Jenkins master.

          Good question about artifacts.  You want to have some child jobs produce artifacts and others not.  By default, Jenkins doesn't allow this.  You can fix this by starting Jenkins with an extra command-line parameter.  I edited the file /etc/default/jenkins to add the following to the line that begins:  JAVA_ARGS="

          • -Dhudson.tasks.ArtifactArchiver.warnOnEmpty=true
          1. This is great. It works nicely. Thanks a lot for your advice!

  9. Hi ,

    question what do you mean with a parent build job.

    Do you mean a upstream build job from the Parameterized Trigger Plugin.

    Is this mean or other jobs or upstream build jobs and other?

    Can someone help to undersatandit.

    Thanks in advance.

    Ingo