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

Ability to build on configurable subset of matrix configurations

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Component/s: matrix-project-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            mdonohue 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.

            Show
            mdonohue 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.
            Hide
            mdonohue mdonohue added a comment -
                • Issue 2353 has been marked as a duplicate of this issue. ***
            Show
            mdonohue mdonohue added a comment - Issue 2353 has been marked as a duplicate of this issue. ***
            Hide
            mdonohue mdonohue added a comment -
                • Issue 3867 has been marked as a duplicate of this issue. ***
            Show
            mdonohue mdonohue added a comment - Issue 3867 has been marked as a duplicate of this issue. ***
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            huybrechts huybrechts added a comment -

            oops, closed the wrong issue

            Show
            huybrechts huybrechts added a comment - oops, closed the wrong issue
            Hide
            lars_kruse 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!

            Show
            lars_kruse 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!
            Hide
            wolfgang 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.

            Show
            wolfgang 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.
            Hide
            wolfgang Christian Wolfgang added a comment -

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

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

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

            Show
            wolfgang Christian Wolfgang added a comment - Btw the modifications to MatrixBuild is just empty lines and MatrixRun is just for my small mock up test.
            Hide
            dty 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.

            Show
            dty 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.
            Hide
            lars_kruse 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!

            Show
            lars_kruse 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!
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            dogfood 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
            Show
            dogfood 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
            Hide
            wolfgang 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.

            Show
            wolfgang 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.
            Hide
            wolfgang Christian Wolfgang added a comment -

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

            Show
            wolfgang Christian Wolfgang added a comment - I have submitted a pull request fixing this issue: https://github.com/jenkinsci/jenkins/pull/133
            Hide
            brian 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.

            Show
            brian 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.
            Hide
            brian Brian Murrell added a comment -

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

            Show
            brian Brian Murrell added a comment - Is there any projected time frame in which UI exposing this feature will be available?
            Hide
            wolfgang 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.

            Show
            wolfgang 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.
            Hide
            brian 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?

            Show
            brian 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?
            Hide
            wolfgang 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.

            Show
            wolfgang 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            salimfadhley 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

            Show
            salimfadhley 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            rayeesn 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 ?

            Show
            rayeesn 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 ?

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: