Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-1613

Ability to build on configurable subset of matrix configurations

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • matrix-project-plugin
    • None
    • Platform: All, OS: All

      It is useful sometimes to perform build on predefined number of slave builders
      assigned to multi-configuration job. For example, if some OS builds failed, and
      we wish to re-build only them after code fixed

          [JENKINS-1613] Ability to build on configurable subset of matrix configurations

          mdonohue added a comment -

          This problem isn't exclusive to slave selection, as I understand the matrix
          build feature, so I've updated the summary.

          Also see issue 3332, which would allow a canary configuration to run first, and
          only run the rest of the matrix configurations if the canary succeeds. This
          would cut down on massive failure notification.

          mdonohue added a comment - This problem isn't exclusive to slave selection, as I understand the matrix build feature, so I've updated the summary. Also see issue 3332, which would allow a canary configuration to run first, and only run the rest of the matrix configurations if the canary succeeds. This would cut down on massive failure notification.

          mdonohue added a comment -
              • Issue 2353 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 2353 has been marked as a duplicate of this issue. ***

          mdonohue added a comment -
              • Issue 3867 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 3867 has been marked as a duplicate of this issue. ***

          Code changed in hudson
          User: : huybrechts
          Path:
          trunk/hudson/main/core/src/main/java/hudson/matrix/MatrixBuild.java
          trunk/hudson/main/core/src/main/java/hudson/matrix/MatrixProject.java
          trunk/hudson/main/core/src/main/java/hudson/model/Result.java
          trunk/hudson/main/core/src/main/resources/hudson/matrix/MatrixProject/configure-entries.jelly
          trunk/hudson/main/test/src/main/java/org/jvnet/hudson/test/FailureBuilder.java
          trunk/hudson/main/test/src/main/java/org/jvnet/hudson/test/UnstableBuilder.java
          trunk/hudson/main/test/src/main/resources/org/jvnet/hudson/test/UnstableBuilder/config.jelly
          trunk/hudson/main/test/src/test/java/hudson/matrix/MatrixProjectTest.java
          trunk/hudson/main/war/resources/help/matrix/touchstone.html
          http://fisheye4.cenqua.com/changelog/hudson/?cs=20737
          Log:
          [FIXED JENKINS-1613] implements touchstone build for matrix projects, which runs a selected number of configurations first and then all the rests if these succeed

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : huybrechts Path: trunk/hudson/main/core/src/main/java/hudson/matrix/MatrixBuild.java trunk/hudson/main/core/src/main/java/hudson/matrix/MatrixProject.java trunk/hudson/main/core/src/main/java/hudson/model/Result.java trunk/hudson/main/core/src/main/resources/hudson/matrix/MatrixProject/configure-entries.jelly trunk/hudson/main/test/src/main/java/org/jvnet/hudson/test/FailureBuilder.java trunk/hudson/main/test/src/main/java/org/jvnet/hudson/test/UnstableBuilder.java trunk/hudson/main/test/src/main/resources/org/jvnet/hudson/test/UnstableBuilder/config.jelly trunk/hudson/main/test/src/test/java/hudson/matrix/MatrixProjectTest.java trunk/hudson/main/war/resources/help/matrix/touchstone.html http://fisheye4.cenqua.com/changelog/hudson/?cs=20737 Log: [FIXED JENKINS-1613] implements touchstone build for matrix projects, which runs a selected number of configurations first and then all the rests if these succeed

          huybrechts added a comment -

          oops, closed the wrong issue

          huybrechts added a comment - oops, closed the wrong issue

          Lars Kruse added a comment -

          I've assigned this case to myself.

          We ('Christian Wolfgang' and myself) are researching and we will present a design proposal for a simple and elegant solution to this problem within a few days.

          Hope to get feed-back on the design from the community before we start implementing.

          Stay tuned!

          Lars Kruse added a comment - I've assigned this case to myself. We ('Christian Wolfgang' and myself) are researching and we will present a design proposal for a simple and elegant solution to this problem within a few days. Hope to get feed-back on the design from the community before we start implementing. Stay tuned!

          Modifications to Jenkins-core
          -----------------------------

          The general idea of the design is being able to differentiate between matrix configurations reusing(copying) older builds(a basis build) and configurations actual being rebuild, without disturbing older non-reusing projects' configurations.
          For this to work we need to alter the Jenkins core at the very lowest level, where the job is run. This is done in the abstract class Run, in the method run(). This method has two points of interest:

          • job.run(listener)
          • job.post(listener)
            Cutting of these two calls, we can achieve a build, that looks like it was run correctly, setting the build result as we want(=the same result as the basis build). Being able to create a Run object, whose values are set, we only need to copy the artifacts from the basis builds, the ones that are not rebuild. This can be achieved by adding some extra functionality to the AbstractBuild class. Currently, as it can be viewed in the code, the build directory of the basis build is hard copied to the source build, only leaving out build.xml. The build.xml file is created by Jenkins after the job is run and would cause an exception.

          To distinguish between builds that should be rebuild and builds that should not, we need to add a property to the Run class. We have added a small class called ReuseRun, that only implements an integer referencing the rebuild build. If this object is either null or the integer is 0, the new functionality is left untouched. This object is null for all projects not using the rebuild functionality.

          Though this is a prototype, we consider this a functional starting point, based on the fact that Run objects will, by default, instantiate the ReuseRun object to null. Thus only explicit calls to setReuse can change that and the code added is only related to the object being not null.

          Christian Wolfgang added a comment - Modifications to Jenkins-core ----------------------------- The general idea of the design is being able to differentiate between matrix configurations reusing(copying) older builds(a basis build) and configurations actual being rebuild, without disturbing older non-reusing projects' configurations. For this to work we need to alter the Jenkins core at the very lowest level, where the job is run. This is done in the abstract class Run, in the method run(). This method has two points of interest: job.run(listener) job.post(listener) Cutting of these two calls, we can achieve a build, that looks like it was run correctly, setting the build result as we want(=the same result as the basis build). Being able to create a Run object, whose values are set, we only need to copy the artifacts from the basis builds, the ones that are not rebuild. This can be achieved by adding some extra functionality to the AbstractBuild class. Currently, as it can be viewed in the code, the build directory of the basis build is hard copied to the source build, only leaving out build.xml. The build.xml file is created by Jenkins after the job is run and would cause an exception. To distinguish between builds that should be rebuild and builds that should not, we need to add a property to the Run class. We have added a small class called ReuseRun, that only implements an integer referencing the rebuild build. If this object is either null or the integer is 0, the new functionality is left untouched. This object is null for all projects not using the rebuild functionality. Though this is a prototype, we consider this a functional starting point, based on the fact that Run objects will, by default, instantiate the ReuseRun object to null. Thus only explicit calls to setReuse can change that and the code added is only related to the object being not null.

          I have committed the initial code draft at https://github.com/Praqma/jenkins/compare/master

          Christian Wolfgang added a comment - I have committed the initial code draft at https://github.com/Praqma/jenkins/compare/master

          Btw the modifications to MatrixBuild is just empty lines and MatrixRun is just for my small mock up test.

          Christian Wolfgang added a comment - Btw the modifications to MatrixBuild is just empty lines and MatrixRun is just for my small mock up test.

          Dean Yu added a comment -

          In the situation where the build you are re-using does not exist, you are failing the matrix build. Why is failing the build better than rebuilding that configuration?

          I also see that you haven't provided UI changes yet. How do you think this functionality would be exposed? I imagine you could add a Rebuild action to the left side navigation, which would take the user to a page where they can pick the configuration subset they want to rebuild. Maybe there's another way to do this that I didn't consider.

          A fundamental problem I see with this capability is that it requires a human to know that it's safe to only rebuild parts of the matrix. Going back to the original issue description, if the person doing the rebuild doesn't realize that the code change also affects another OS that doesn't get rebuilt, then you have failed to test a necessary configuration. This also then bubbles up into release management. You probably want to tag your version control at the point of release, but if some of your configurations were built with older versions and not rebuilt, you've lost that information.

          Dean Yu added a comment - In the situation where the build you are re-using does not exist, you are failing the matrix build. Why is failing the build better than rebuilding that configuration? I also see that you haven't provided UI changes yet. How do you think this functionality would be exposed? I imagine you could add a Rebuild action to the left side navigation, which would take the user to a page where they can pick the configuration subset they want to rebuild. Maybe there's another way to do this that I didn't consider. A fundamental problem I see with this capability is that it requires a human to know that it's safe to only rebuild parts of the matrix. Going back to the original issue description, if the person doing the rebuild doesn't realize that the code change also affects another OS that doesn't get rebuilt, then you have failed to test a necessary configuration. This also then bubbles up into release management. You probably want to tag your version control at the point of release, but if some of your configurations were built with older versions and not rebuilt, you've lost that information.

          Lars Kruse added a comment -

          Hi Dean, thanks for feed back - Good questions.

          Why fail rather than rebuild if the configuration is missing? Well we think like this: In the case where we need to make the choice, the user obviously asked for a reuse - not a rebuild. Potentially a rebuild can take a long time - so it's likely that our guess will not always capture the users intend or wish. Therefore we choose to fail the build and print to the log what happened - simply because it's faster, and this way we're not assuming anything. Then the user (yes - there IS a human involved in this feature) can schedule another rebuild, only this time he explicitly asks for a rebuild - not a reuse.

          You are right about your assumptions regarding the UI (we will present a mock-up of what we have in mind very soon) but in large: A rebuild action that takes you to a new form listing all the results in the matrix from the previous build, each cell in the matrix now has a small checkbox attached to it. The user checks the builds in the matrix he/she wants to rebuild - the other ones are reused. There will be short cuts like "select all failed", "select all unstable" ...etc. When the user hits submit, the choices are traversed and all the builds that shall be reused will have the ReuseRun attribute set.

          Our plan is to extend the ability to reuse a build in the core (as presented here) and then we will release the form that utilizes it as a seperate (new) plugin.

          ...leading to your third question - or concern: It requires a knowning human! Yes! The scenario we see for this reuse/rebuild feature is:
          In a large matrix some (most) configurations has succeeded, a few have failed or are unstable. Going through the logs it appears that it's due to the slaves configuration or abilities that something went wrong (say a process hung or a network connection was lost or it failed to get a license to tool it depended on....) Now you don't want to rebuild the entire matrix again (imagine that it takes several hours to do that). You just pick the failed builds and ask to reuse the successful ones. We imagine that the configurations that are rerun will still honour all the various other settings of the job, thus if the job picks latest commit on a branch, and there is a new commit - then you are right it's a different build then before.

          We imagine that users must take the necessary steps in their job configurations to avoid mistakes like this to happen. In our setup we're building a named commit, so it's safe - for us

          The thing is, we realize that the behaviour we're looking for might be special, but the aproach to how we implemented it (in AbstractBuild and Run) is generic. Other plugins could use the same feature to make different behaviour - either by contributing to our plugin or by creating a new one. The design should support that no more extensions are needed in the core to make either work.

          Hmmm - But to avoid making future changes to the core on behalf of others in the future would rather rebuild than fail the build, then I guess we could extend the ReuseRun object to be able to carry such information (rebuildIfMissing) and act accordingly. We could set it to FALSE as default and get the same behaviour. Would that work?

          Again, Thanks for feed back, it's very welcome!

          Lars Kruse added a comment - Hi Dean, thanks for feed back - Good questions. Why fail rather than rebuild if the configuration is missing? Well we think like this: In the case where we need to make the choice, the user obviously asked for a reuse - not a rebuild. Potentially a rebuild can take a long time - so it's likely that our guess will not always capture the users intend or wish. Therefore we choose to fail the build and print to the log what happened - simply because it's faster, and this way we're not assuming anything. Then the user (yes - there IS a human involved in this feature) can schedule another rebuild, only this time he explicitly asks for a rebuild - not a reuse. You are right about your assumptions regarding the UI (we will present a mock-up of what we have in mind very soon) but in large: A rebuild action that takes you to a new form listing all the results in the matrix from the previous build, each cell in the matrix now has a small checkbox attached to it. The user checks the builds in the matrix he/she wants to rebuild - the other ones are reused. There will be short cuts like "select all failed", "select all unstable" ...etc. When the user hits submit, the choices are traversed and all the builds that shall be reused will have the ReuseRun attribute set. Our plan is to extend the ability to reuse a build in the core (as presented here) and then we will release the form that utilizes it as a seperate (new) plugin. ...leading to your third question - or concern: It requires a knowning human! Yes! The scenario we see for this reuse/rebuild feature is: In a large matrix some (most) configurations has succeeded, a few have failed or are unstable. Going through the logs it appears that it's due to the slaves configuration or abilities that something went wrong (say a process hung or a network connection was lost or it failed to get a license to tool it depended on....) Now you don't want to rebuild the entire matrix again (imagine that it takes several hours to do that). You just pick the failed builds and ask to reuse the successful ones. We imagine that the configurations that are rerun will still honour all the various other settings of the job, thus if the job picks latest commit on a branch, and there is a new commit - then you are right it's a different build then before. We imagine that users must take the necessary steps in their job configurations to avoid mistakes like this to happen. In our setup we're building a named commit, so it's safe - for us The thing is, we realize that the behaviour we're looking for might be special, but the aproach to how we implemented it (in AbstractBuild and Run) is generic. Other plugins could use the same feature to make different behaviour - either by contributing to our plugin or by creating a new one. The design should support that no more extensions are needed in the core to make either work. Hmmm - But to avoid making future changes to the core on behalf of others in the future would rather rebuild than fail the build, then I guess we could extend the ReuseRun object to be able to carry such information (rebuildIfMissing) and act accordingly. We could set it to FALSE as default and get the same behaviour. Would that work? Again, Thanks for feed back, it's very welcome!

          Code changed in jenkins
          User: Christian Wolfgang
          Path:
          core/src/main/java/hudson/matrix/MatrixBuild.java
          core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java
          http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4
          Log:
          More on JENKINS-1613

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Wolfgang Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4 Log: More on JENKINS-1613

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48
          Log:
          [FIXED JENKINS-1613] Ability to build on configurable subset of matrix
          configurations

          This change introduces the necessary extension point. The implementation
          of this will be in a plugin.

          Compare: https://github.com/jenkinsci/jenkins/compare/f10b5eb...0203876

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48 Log: [FIXED JENKINS-1613] Ability to build on configurable subset of matrix configurations This change introduces the necessary extension point. The implementation of this will be in a plugin. Compare: https://github.com/jenkinsci/jenkins/compare/f10b5eb...0203876

          Code changed in jenkins
          User: Christian Wolfgang
          Path:
          core/src/main/java/hudson/matrix/MatrixBuild.java
          core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java
          http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4
          Log:
          More on JENKINS-1613

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Wolfgang Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4 Log: More on JENKINS-1613

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48
          Log:
          [FIXED JENKINS-1613] Ability to build on configurable subset of matrix
          configurations

          This change introduces the necessary extension point. The implementation
          of this will be in a plugin.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48 Log: [FIXED JENKINS-1613] Ability to build on configurable subset of matrix configurations This change introduces the necessary extension point. The implementation of this will be in a plugin.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #791
          More on JENKINS-1613
          [FIXED JENKINS-1613] Ability to build on configurable subset of matrix

          Christian Wolfgang : f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4
          Files :

          • core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java
          • core/src/main/java/hudson/matrix/MatrixBuild.java

          Kohsuke Kawaguchi : 0203876cb01f0cfee1c790a3102a3508ff4f6a48
          Files :

          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #791 More on JENKINS-1613 [FIXED JENKINS-1613] Ability to build on configurable subset of matrix Christian Wolfgang : f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4 Files : core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java core/src/main/java/hudson/matrix/MatrixBuild.java Kohsuke Kawaguchi : 0203876cb01f0cfee1c790a3102a3508ff4f6a48 Files : changelog.html

          Given the problems arisen by rebuilt matrices composed of several different matrix builds, turns out to be too big.
          Thus the demand for rebuilding a matrix from a specific matrix build is required.
          This requirement needs to be build into the core.

          Christian Wolfgang added a comment - Given the problems arisen by rebuilt matrices composed of several different matrix builds, turns out to be too big. Thus the demand for rebuilding a matrix from a specific matrix build is required. This requirement needs to be build into the core.

          I have submitted a pull request fixing this issue: https://github.com/jenkinsci/jenkins/pull/133

          Christian Wolfgang added a comment - I have submitted a pull request fixing this issue: https://github.com/jenkinsci/jenkins/pull/133

          Brian Murrell added a comment -

          thus if the job picks latest commit on a branch, and there is a new commit - then you are right it's a different build then before.

          Doesn't every job (that builds from an SCM) have some sort of "bookmark" (i.e. the commit hash in git) of the point in the SCM's history where a build was done? Couldn't this "rebuild" feature ensure that the SCM checkout is done at that "bookmark" rather than the latest as it usually is supposed to do?

          That would then ensure that you don't have a different build than the one you are rebuilding.

          Brian Murrell added a comment - thus if the job picks latest commit on a branch, and there is a new commit - then you are right it's a different build then before. Doesn't every job (that builds from an SCM) have some sort of "bookmark" (i.e. the commit hash in git) of the point in the SCM's history where a build was done? Couldn't this "rebuild" feature ensure that the SCM checkout is done at that "bookmark" rather than the latest as it usually is supposed to do? That would then ensure that you don't have a different build than the one you are rebuilding.

          Brian Murrell added a comment -

          Is there any projected time frame in which UI exposing this feature will be available?

          Brian Murrell added a comment - Is there any projected time frame in which UI exposing this feature will be available?

          Christian Wolfgang added a comment - - edited

          Yes, the core changes are in 1.416, so my guess is this upcoming Monday.
          I will release the plugin when 1.416 is released.

          Christian Wolfgang added a comment - - edited Yes, the core changes are in 1.416, so my guess is this upcoming Monday. I will release the plugin when 1.416 is released.

          Brian Murrell added a comment -

          Yes, the core changes are in 1.416, so my guess is this upcoming Monday.

          Oh. I thought this went into 1.413. From the Changelog:

          What's new in 1.413 (2011/05/22)
          ...
          Support rebuilding a subset of matrix configurations (issue 1613)
          ...

          Was the commit to 1.413 incomplete perhaps?

          Brian Murrell added a comment - Yes, the core changes are in 1.416, so my guess is this upcoming Monday. Oh. I thought this went into 1.413. From the Changelog: What's new in 1.413 (2011/05/22) ... Support rebuilding a subset of matrix configurations (issue 1613) ... Was the commit to 1.413 incomplete perhaps?

          Somewhat. The 1.413 always bases its rebuild from the latest successful build, the new change can base from any build.

          Christian Wolfgang added a comment - Somewhat. The 1.413 always bases its rebuild from the latest successful build, the new change can base from any build.

          Code changed in jenkins
          User: Christian Wolfgang
          Path:
          core/src/main/java/hudson/matrix/MatrixBuild.java
          core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java
          http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4
          Log:
          More on JENKINS-1613

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Wolfgang Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4 Log: More on JENKINS-1613

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48
          Log:
          [FIXED JENKINS-1613] Ability to build on configurable subset of matrix
          configurations

          This change introduces the necessary extension point. The implementation
          of this will be in a plugin.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48 Log: [FIXED JENKINS-1613] Ability to build on configurable subset of matrix configurations This change introduces the necessary extension point. The implementation of this will be in a plugin.

          Code changed in jenkins
          User: Christian Wolfgang
          Path:
          core/src/main/java/hudson/matrix/MatrixBuild.java
          core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java
          http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4
          Log:
          More on JENKINS-1613

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Wolfgang Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java http://jenkins-ci.org/commit/jenkins/f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4 Log: More on JENKINS-1613

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48
          Log:
          [FIXED JENKINS-1613] Ability to build on configurable subset of matrix
          configurations

          This change introduces the necessary extension point. The implementation
          of this will be in a plugin.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html http://jenkins-ci.org/commit/jenkins/0203876cb01f0cfee1c790a3102a3508ff4f6a48 Log: [FIXED JENKINS-1613] Ability to build on configurable subset of matrix configurations This change introduces the necessary extension point. The implementation of this will be in a plugin.

          salimfadhley added a comment -

          One problem with the current implementation is it's effect on the build history graph - suppose you incrementally re-run parts of an unreliable matrix build, it gives the impression that the number of tests in each run are diminishing - when in actual fact the number of tests remain constant, we are just running a smaller subset.

          Would it be possible to alter this so that results from previous runs which are not re-executed by Matrix Reloaded are carried forwards. That means I'd like to see the height of the bar-graph remain constant with the red proportion gradually diminishing with each additional build.

          Here's a slightly exaggerated screenshot which illustrates the problem:

          http://imgur.com/HEV9J

          salimfadhley added a comment - One problem with the current implementation is it's effect on the build history graph - suppose you incrementally re-run parts of an unreliable matrix build, it gives the impression that the number of tests in each run are diminishing - when in actual fact the number of tests remain constant, we are just running a smaller subset. Would it be possible to alter this so that results from previous runs which are not re-executed by Matrix Reloaded are carried forwards. That means I'd like to see the height of the bar-graph remain constant with the red proportion gradually diminishing with each additional build. Here's a slightly exaggerated screenshot which illustrates the problem: http://imgur.com/HEV9J

          Code changed in jenkins
          User: Christian Wolfgang
          Path:
          core/src/main/java/hudson/matrix/MatrixBuild.java
          core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java
          http://jenkins-ci.org/commit/matrix-project-plugin/1b135d4cbc08da6959faf63842023962276675c8
          Log:
          More on JENKINS-1613

          Originally-Committed-As: f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christian Wolfgang Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java http://jenkins-ci.org/commit/matrix-project-plugin/1b135d4cbc08da6959faf63842023962276675c8 Log: More on JENKINS-1613 Originally-Committed-As: f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4

          Subset start jobs with new Run number, it will generate separate report;

          Is it possible to make option to append result with its parent job number ?

          Example Executed Job 100, there are 5 failure, if you rebuild the subset, starting job from 101; instead of this can append this with 100 itself ?

          Rayees Namathponnan added a comment - Subset start jobs with new Run number, it will generate separate report; Is it possible to make option to append result with its parent job number ? Example Executed Job 100, there are 5 failure, if you rebuild the subset, starting job from 101; instead of this can append this with 100 itself ?

            wolfgang Christian Wolfgang
            jazzjack jazzjack
            Votes:
            12 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: