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

"Restrict where this project can be run" removed/disabled after Save/Apply of Job Configuration

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • clearcase-plugin, core
    • None
    • Jenkins ver. 1.589, 1.590
      Latest Plugins
      Solaris 10
      Firefox + Chrome
      Maven Build Job

      The host parameters for "Restrict where this project can be run" are removed/disabled after Save/Apply of Job Configuration !!!

      The builds are running on any host not at the specified ones

          [JENKINS-25533] "Restrict where this project can be run" removed/disabled after Save/Apply of Job Configuration

          Oleg Nenashev added a comment - - edited

          Related to JENKINS-25372, which has been caused by https://github.com/jenkinsci/jenkins/pull/1414. There were new fixes in 1.589.
          Have you seen the issue on the previous versions? (it would be great to know this version)

          Oleg Nenashev added a comment - - edited Related to JENKINS-25372 , which has been caused by https://github.com/jenkinsci/jenkins/pull/1414 . There were new fixes in 1.589. Have you seen the issue on the previous versions? (it would be great to know this version)

          podskalsky added a comment -

          I've updated from Jenkins ver. 1.585 to 1.589 - before this update everything was OK!

          podskalsky added a comment - I've updated from Jenkins ver. 1.585 to 1.589 - before this update everything was OK!

          Dirk Kuypers added a comment -

          We updated from 1.588 and see this behaviour with the newest version. Downgrade will take another hour....

          Dirk Kuypers added a comment - We updated from 1.588 and see this behaviour with the newest version. Downgrade will take another hour....

          Oleg Nenashev added a comment -

          Added mattmoor to Cc

          Oleg Nenashev added a comment - Added mattmoor to Cc

          Martin Beller added a comment -

          We upgraded from 1.588 to 1.589 and see this behaviour with the newest version. A downgrade to 1.588 solves the problem.

          Martin Beller added a comment - We upgraded from 1.588 to 1.589 and see this behaviour with the newest version. A downgrade to 1.588 solves the problem.

          Daniel Beck added a comment -

          What project types are affected?

          Daniel Beck added a comment - What project types are affected?

          Dirk Kuypers added a comment -

          In our case normal freestyle projects

          Dirk Kuypers added a comment - In our case normal freestyle projects

          podskalsky added a comment -

          in my case a maven project

          podskalsky added a comment - in my case a maven project

          podskalsky added a comment -

          Bug still existing at Jenkins 1.590

          podskalsky added a comment - Bug still existing at Jenkins 1.590

          podskalsky added a comment - - edited

          The "newline" of my config.xml is removed and alse the parameters assignedNode + canRoam ...

          $ diff config.xml config.ok
          Warning: missing newline at end of file config.xml
          57c57,58
          < <canRoam>true</canRoam>
          —
          > <assignedNode>master</assignedNode>
          > <canRoam>false</canRoam>
          197c198
          < </maven2-moduleset>
          —
          > </maven2-moduleset>

          podskalsky added a comment - - edited The "newline" of my config.xml is removed and alse the parameters assignedNode + canRoam ... $ diff config.xml config.ok Warning: missing newline at end of file config.xml 57c57,58 < <canRoam>true</canRoam> — > <assignedNode>master</assignedNode> > <canRoam>false</canRoam> 197c198 < </maven2-moduleset> — > </maven2-moduleset>

          Daniel Beck added a comment -

          podskalsky: Jenkins does not add trailing newlines to XML files, I assume those are yours? (JENKINS-25628)

          Daniel Beck added a comment - podskalsky : Jenkins does not add trailing newlines to XML files, I assume those are yours? ( JENKINS-25628 )

          podskalsky added a comment -

          The trailing newlines are not the problem (I've checked it) but the changed xml tag canRoam and the removed tag assignedNode !!!

          podskalsky added a comment - The trailing newlines are not the problem (I've checked it) but the changed xml tag canRoam and the removed tag assignedNode !!!

          Daniel Beck added a comment -

          podskalsky: You edited your comment to include that information, so it seemed you considered that important for some reason.

          Daniel Beck added a comment - podskalsky : You edited your comment to include that information, so it seemed you considered that important for some reason.

          Daniel Beck added a comment -

          I cannot reproduce this on a pristine Jenkins 1.592 SNAPSHOT (current development version) with either freestyle or Maven projects. Adding the restriction works, and subsequent edits of the form keep it unmodified. I can see no changes between 1.590 and my version.

          Any further information you could provide under what circumstances the issue appears? Could someone maybe capture the form submit HTTP request of their browsr when configuring a test project, and provide the submitted form JSON?

          Daniel Beck added a comment - I cannot reproduce this on a pristine Jenkins 1.592 SNAPSHOT (current development version) with either freestyle or Maven projects. Adding the restriction works, and subsequent edits of the form keep it unmodified. I can see no changes between 1.590 and my version. Any further information you could provide under what circumstances the issue appears? Could someone maybe capture the form submit HTTP request of their browsr when configuring a test project, and provide the submitted form JSON?

          Martin Beller added a comment -

          I tested with Jenkins 1590 and the problem is still not solved (as indicated by Andreas above). Here are the logs in case the job configuration is saved:

          Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.tasks.LogRotator
          Nov 22, 2014 10:34:06 AM hudson.model.AbstractProject submit
          WARNING: label assignment is using legacy '_.assignedLabelString'
          Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.impl.AbsoluteTimeOutStrategy
          Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.operations.FailOperation
          Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.tasks.Shell
          Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.plugins.warnings.WarningsPublisher
          Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.tasks.Mailer

          Any other information I could provide to track down the issue?

          Martin Beller added a comment - I tested with Jenkins 1590 and the problem is still not solved (as indicated by Andreas above). Here are the logs in case the job configuration is saved: Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.tasks.LogRotator Nov 22, 2014 10:34:06 AM hudson.model.AbstractProject submit WARNING: label assignment is using legacy '_.assignedLabelString' Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.impl.AbsoluteTimeOutStrategy Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.operations.FailOperation Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.tasks.Shell Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.plugins.warnings.WarningsPublisher Nov 22, 2014 10:34:06 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.tasks.Mailer Any other information I could provide to track down the issue?

          Martin Beller added a comment -

          An here are the logs if I do the same operation with Jenkins 1588 (problem does not occur):

          Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.tasks.LogRotator
          Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.impl.AbsoluteTimeOutStrategy
          Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.operations.FailOperation
          Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.tasks.Shell
          Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.plugins.warnings.WarningsPublisher
          Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON
          WARNING: 'stapler-class' is deprecated: hudson.tasks.Mailer
          Nov 22, 2014 10:52:07 AM hudson.slaves.SlaveComputer tryReconnect

          Martin Beller added a comment - An here are the logs if I do the same operation with Jenkins 1588 (problem does not occur): Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.tasks.LogRotator Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.impl.AbsoluteTimeOutStrategy Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.plugins.build_timeout.operations.FailOperation Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.tasks.Shell Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.plugins.warnings.WarningsPublisher Nov 22, 2014 10:51:00 AM org.kohsuke.stapler.RequestImpl$TypePair convertJSON WARNING: 'stapler-class' is deprecated: hudson.tasks.Mailer Nov 22, 2014 10:52:07 AM hudson.slaves.SlaveComputer tryReconnect

          Daniel Beck added a comment -

          mbeller: What kind of project (Freestyle, Maven, Matrix/multiconfig, MultiJob, Build Flow, Workflow, ...) is that?

          I now tried it on a regular instance with 1.590. Still cannot reproduce it with freestyle projects.

          Daniel Beck added a comment - mbeller : What kind of project (Freestyle, Maven, Matrix/multiconfig, MultiJob, Build Flow, Workflow, ...) is that? I now tried it on a regular instance with 1.590. Still cannot reproduce it with freestyle projects.

          Martin Beller added a comment -

          I could reproduce the issue with a Freestyle test project. Here is the submitted JSON (Firefox 33.1.1):

          {"name": "MBeTest", "description": "", "": ["", "0"], "logrotate": false, "buildDiscarder": {"stapler-class": "hudson.tasks.LogRotator", "daysToKeepStr": "", "numToKeepStr": "", "artifactDaysToKeepStr": "", "artifactNumToKeepStr": ""}, "properties": {"stapler-class-bag": "true", "hudson-model-ParametersDefinitionProperty": {}, "org-jenkinsci-plugins-envinject-EnvInjectJobProperty": {}}, "disable": false, "concurrentBuild": false, "hasSlaveAffinity": true, "label": "buildServer", "hasCustomQuietPeriod": false, "quiet_period": "5", "hasCustomScmCheckoutRetryCount": false, "scmCheckoutRetryCount": "0", "blockBuildWhenUpstreamBuilding": false, "blockBuildWhenDownstreamBuilding": false, "hasCustomWorkspace": false, "customWorkspace": "", "displayNameOrNull": "", "scm": {"value": "0"}, "core:apply": "true"}
          

          Martin Beller added a comment - I could reproduce the issue with a Freestyle test project. Here is the submitted JSON (Firefox 33.1.1): {"name": "MBeTest", "description": "", "": ["", "0"], "logrotate": false, "buildDiscarder": {"stapler-class": "hudson.tasks.LogRotator", "daysToKeepStr": "", "numToKeepStr": "", "artifactDaysToKeepStr": "", "artifactNumToKeepStr": ""}, "properties": {"stapler-class-bag": "true", "hudson-model-ParametersDefinitionProperty": {}, "org-jenkinsci-plugins-envinject-EnvInjectJobProperty": {}}, "disable": false, "concurrentBuild": false, "hasSlaveAffinity": true, "label": "buildServer", "hasCustomQuietPeriod": false, "quiet_period": "5", "hasCustomScmCheckoutRetryCount": false, "scmCheckoutRetryCount": "0", "blockBuildWhenUpstreamBuilding": false, "blockBuildWhenDownstreamBuilding": false, "hasCustomWorkspace": false, "customWorkspace": "", "displayNameOrNull": "", "scm": {"value": "0"}, "core:apply": "true"}

          Daniel Beck added a comment -

          To clarify, after you submit this, you click "Configure", and "Restrict where" is not checked, and/or the label expression is empty? And submitting the form results in the warning?

          Still cannot reproduce this (on ~1.592 again). My JSON is identical except for the presumably bogus "": ["", "0"] element, I even installed env-inject to get the empty property.

          Daniel Beck added a comment - To clarify, after you submit this, you click "Configure", and "Restrict where" is not checked, and/or the label expression is empty? And submitting the form results in the warning? Still cannot reproduce this (on ~1.592 again). My JSON is identical except for the presumably bogus "": ["", "0"] element, I even installed env-inject to get the empty property.

          Martin Beller added a comment -

          screenshot before pressing the Apply or Save button

          Martin Beller added a comment - screenshot before pressing the Apply or Save button

          Martin Beller added a comment - - edited

          Daniel Beck: Please find attached the screenshot MBeTest Config [Jenkins].png before I press the Save or Apply button. The result is the WARNING: label assignment is using legacy '_.assignedLabelString' and the config.xml of the related job is not updated properly.

          Martin Beller added a comment - - edited Daniel Beck: Please find attached the screenshot MBeTest Config [Jenkins] .png before I press the Save or Apply button. The result is the WARNING: label assignment is using legacy '_.assignedLabelString' and the config.xml of the related job is not updated properly.

          podskalsky added a comment -

          @Martin: thank you for your additional input and log files.
          On my server I've downgraded to 1.588. So I'm not not able to generate these log files.

          podskalsky added a comment - @Martin: thank you for your additional input and log files. On my server I've downgraded to 1.588. So I'm not not able to generate these log files.

          Daniel Beck added a comment -

          As I wrote above, I'm sending almost exactly the same data, and it's processed correctly on the server, despite using 1.590. Uploading another screenshot of the same form field doesn't help (or I don't understand what it signifies, in that case, please explain).

          Is anyone able to reproduce this issue on a pristine Jenkins instance? How about after installing all the plugins you have on your prod instance (in the same versions)? If it works out of the box but installing plugins results in a problem, try to determine which plugin is responsible by disabling/enabling them until you find the culprit.

          Daniel Beck added a comment - As I wrote above, I'm sending almost exactly the same data, and it's processed correctly on the server, despite using 1.590. Uploading another screenshot of the same form field doesn't help (or I don't understand what it signifies, in that case, please explain). Is anyone able to reproduce this issue on a pristine Jenkins instance? How about after installing all the plugins you have on your prod instance (in the same versions)? If it works out of the box but installing plugins results in a problem, try to determine which plugin is responsible by disabling/enabling them until you find the culprit.

          Martin Beller added a comment -

          @Daniel:

          • Do you get the same Warning (label assignment is using legacy '_.assignedLabelString') when pressing the Save/Apply button?
          • Did you verify that the config.xml file of the related job is updated properly:
             
              <assignedNode>buildServer</assignedNode>
              <canRoam>false</canRoam>
            

          Martin Beller added a comment - @Daniel: Do you get the same Warning (label assignment is using legacy '_.assignedLabelString') when pressing the Save/Apply button? Did you verify that the config.xml file of the related job is updated properly: <assignedNode>buildServer</assignedNode> <canRoam>false</canRoam>

          I see the same issue after upgrading from 1.588 to 1.590
          I have the same plugins in both versions and it works with 1.588 and is broken in 1.590

          Reinhard Karbas added a comment - I see the same issue after upgrading from 1.588 to 1.590 I have the same plugins in both versions and it works with 1.588 and is broken in 1.590

          Can I suggest that people who have this problem give a list of the plugins that they have.
          Thanks

          Matthew Webber added a comment - Can I suggest that people who have this problem give a list of the plugins that they have. Thanks

          Added my list of plugins as attachment (jenkins-plugins-rk.doc)

          Reinhard Karbas added a comment - Added my list of plugins as attachment (jenkins-plugins-rk.doc)

          Brian Krische added a comment -

          I did quite a bit of testing an narrowed it down. The issue occurs in Jenkins versions 1.589 or greater when the ClearCase plugin is installed. I didn't test all of the plugins rkarbas had installed, but I first noticed it with the ClearCase plugin. Here are some steps to reproduce:

          1. Install Jenkins 1.589 or higher
          2. Configure a node (Ex. master) with a label of "test"
          3. Create a new Freestyle job and restrict it to the "test" node label
          4. Save the job
          5. Reopen the job's configure page and notice the node label restriction is gone.

          Brian Krische added a comment - I did quite a bit of testing an narrowed it down. The issue occurs in Jenkins versions 1.589 or greater when the ClearCase plugin is installed. I didn't test all of the plugins rkarbas had installed, but I first noticed it with the ClearCase plugin. Here are some steps to reproduce: Install Jenkins 1.589 or higher Configure a node (Ex. master) with a label of "test" Create a new Freestyle job and restrict it to the "test" node label Save the job Reopen the job's configure page and notice the node label restriction is gone.

          Daniel Beck added a comment -

          Great find Brian!


          Could the watchers please chime in?

          • Do you have the ClearCase plugin installed?
            • Does the issue disappear with the plugin disabled (if unused)?
          • Please provide the list of plugins (+versions) if not.

          Daniel Beck added a comment - Great find Brian! Could the watchers please chime in? Do you have the ClearCase plugin installed? Does the issue disappear with the plugin disabled (if unused)? Please provide the list of plugins (+versions) if not.

          Dirk Kuypers added a comment -

          I can confirm that we use the ClearCase plugin in latest version 1.5.3.

          Dirk Kuypers added a comment - I can confirm that we use the ClearCase plugin in latest version 1.5.3.

          Daniel Beck added a comment - - edited

          I can reproduce the problem on a newly set up instance. Disable all bundled plugins, install ClearCase plugin, restart, and there it is.

          label assignment is using legacy '_.assignedLabelString'

          And here's the problem:
          https://github.com/jenkinsci/clearcase-plugin/blob/4e1ac05ac09f17326e1fab4d6af7aa5fda297f94/src/main/resources/hudson/plugins/clearcase/viewstorage/ServerViewStorage/config.jelly#L28

          Daniel Beck added a comment - - edited I can reproduce the problem on a newly set up instance. Disable all bundled plugins, install ClearCase plugin, restart, and there it is. label assignment is using legacy '_.assignedLabelString' And here's the problem: https://github.com/jenkinsci/clearcase-plugin/blob/4e1ac05ac09f17326e1fab4d6af7aa5fda297f94/src/main/resources/hudson/plugins/clearcase/viewstorage/ServerViewStorage/config.jelly#L28

          podskalsky added a comment -

          I can confirm that the ClearCase plugin is the problem.
          I've uninstalled this plugin (I don't need it) and saving data is now OK.

          podskalsky added a comment - I can confirm that the ClearCase plugin is the problem. I've uninstalled this plugin (I don't need it) and saving data is now OK.

          Daniel Beck added a comment -

          Core needs to be more resilient wrt form field names by plugins, so core should be fixed IMO. ClearCase did nothing wrong, just bad interaction.

          Daniel Beck added a comment - Core needs to be more resilient wrt form field names by plugins, so core should be fixed IMO. ClearCase did nothing wrong, just bad interaction.

          I am also observing this issue, using Jenkins 1.591 and Clearcase plugin. It's a major bug to me, as our projects are kept in Clearcase and any edit of job configuration removes target assignments. I appreciate long-term solution for core to be more resilient, but I would also make use of a short-term fix.

          Krzysztof Malinowski added a comment - I am also observing this issue, using Jenkins 1.591 and Clearcase plugin. It's a major bug to me, as our projects are kept in Clearcase and any edit of job configuration removes target assignments. I appreciate long-term solution for core to be more resilient, but I would also make use of a short-term fix.

          Matthew Moore added a comment - - edited

          I'd posit the "fix" is transposing these two predicates in my prior PR:

          if(req.hasParameter("_.assignedLabelString")) {
          // Workaround for JENKINS-25372 while plugin is being updated.
          LOGGER.log(Level.WARNING, "label assignment is using legacy '_.assignedLabelString'");
          assignedNode = Util.fixEmptyAndTrim(req.getParameter("_.assignedLabelString"));
          } else if(json.optBoolean("hasSlaveAffinity", json.has("label"))) {
          assignedNode = Util.fixEmptyAndTrim(json.optString("label"));

          (read: prefer the new way)

          Frankly, prior to my original change in PR 1414, the resolution of "assignedLabelString" for the project was kind of a crap shoot with this plugin installed because the project used:

          if(req.getParameter("hasSlaveAffinity")!=null) {
          assignedNode = Util.fixEmptyAndTrim(req.getParameter("_.assignedLabelString"));

          Since both AbstractProject and ClearCase submit "_.assignedLabelString", which one gets picked when accessed through the request is likely undefined...

          I'll try and find some time to make this change this week and test it with some of the cases affected in 25372 to make sure those don't regress with the conditions transposed.

          Sorry for the delayed response, still catching up from the holiday weekend.

          Matthew Moore added a comment - - edited I'd posit the "fix" is transposing these two predicates in my prior PR: if(req.hasParameter("_.assignedLabelString")) { // Workaround for JENKINS-25372 while plugin is being updated. LOGGER.log(Level.WARNING, "label assignment is using legacy '_.assignedLabelString'"); assignedNode = Util.fixEmptyAndTrim(req.getParameter("_.assignedLabelString")); } else if(json.optBoolean("hasSlaveAffinity", json.has("label"))) { assignedNode = Util.fixEmptyAndTrim(json.optString("label")); (read: prefer the new way) Frankly, prior to my original change in PR 1414, the resolution of "assignedLabelString" for the project was kind of a crap shoot with this plugin installed because the project used: if(req.getParameter("hasSlaveAffinity")!=null) { assignedNode = Util.fixEmptyAndTrim(req.getParameter("_.assignedLabelString")); Since both AbstractProject and ClearCase submit "_.assignedLabelString", which one gets picked when accessed through the request is likely undefined... I'll try and find some time to make this change this week and test it with some of the cases affected in 25372 to make sure those don't regress with the conditions transposed. Sorry for the delayed response, still catching up from the holiday weekend.

          Matthew Moore added a comment -

          Matthew Moore added a comment - Submitted: https://github.com/jenkinsci/jenkins/pull/1477

          Jesse Glick added a comment -

          JIRA link daemon is apparently dead.

          Jesse Glick added a comment - JIRA link daemon is apparently dead.

          Brian Krische added a comment -

          So any idea what release will include this fix?

          Brian Krische added a comment - So any idea what release will include this fix?

          Jesse Glick added a comment -

          1.594, currently in RC.

          Jesse Glick added a comment - 1.594, currently in RC.

          Daniel Beck added a comment - - edited

          (confused comment removed)

          Daniel Beck added a comment - - edited (confused comment removed)

          Jesse Glick added a comment -

          I just updated the changelog; forgot to do so when merging.

          Jesse Glick added a comment - I just updated the changelog; forgot to do so when merging.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3866
          JENKINS-25533 Noting merge of #1477. (Revision 97bc2dd44416ae45e604e634b4d5fcfa839ab2aa)

          Result = SUCCESS
          jesse glick : 97bc2dd44416ae45e604e634b4d5fcfa839ab2aa
          Files :

          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #3866 JENKINS-25533 Noting merge of #1477. (Revision 97bc2dd44416ae45e604e634b4d5fcfa839ab2aa) Result = SUCCESS jesse glick : 97bc2dd44416ae45e604e634b4d5fcfa839ab2aa Files : changelog.html

          Code changed in jenkins
          User: Matt Moore
          Path:
          core/src/main/java/hudson/model/AbstractProject.java
          http://jenkins-ci.org/commit/jenkins/15a24dd637392f32b98fe76e53db8c7be429ce7d
          Log:
          Favor the new style of form submission over the legacy form to fix: JENKINS-25533

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Matt Moore Path: core/src/main/java/hudson/model/AbstractProject.java http://jenkins-ci.org/commit/jenkins/15a24dd637392f32b98fe76e53db8c7be429ce7d Log: Favor the new style of form submission over the legacy form to fix: JENKINS-25533

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/java/hudson/model/AbstractProject.java
          http://jenkins-ci.org/commit/jenkins/a59cf9f37f47a9820a5f5859aa82424c039eb1a6
          Log:
          Merge pull request #1477 from mattmoor/JENKINS-25533

          [FIXED JENKINS-25533] Favor the new style of form submission over the legacy form

          Compare: https://github.com/jenkinsci/jenkins/compare/ed891f6bc0a9...a59cf9f37f47

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/hudson/model/AbstractProject.java http://jenkins-ci.org/commit/jenkins/a59cf9f37f47a9820a5f5859aa82424c039eb1a6 Log: Merge pull request #1477 from mattmoor/ JENKINS-25533 [FIXED JENKINS-25533] Favor the new style of form submission over the legacy form Compare: https://github.com/jenkinsci/jenkins/compare/ed891f6bc0a9...a59cf9f37f47

          Code changed in jenkins
          User: nilleb
          Path:
          src/main/resources/hudson/plugins/mstest/mstest-to-junit.xsl
          src/test/java/hudson/plugins/mstest/MSTestReportConverterTest.java
          src/test/resources/hudson/plugins/mstest/JENKINS-25533+19384.trx
          src/test/resources/hudson/plugins/mstest/JENKINS-25533+19384.xml
          src/test/resources/hudson/plugins/mstest/nilleb_HOST18468 2015-03-18 08_03_36.xml
          http://jenkins-ci.org/commit/mstest-plugin/2b6797a0cc004d7756bcb6d13fbba465389bdac2
          Log:
          [FIXED JENKINS-25533][FIXED JENKINS-19384] support for output/stdout messages

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: nilleb Path: src/main/resources/hudson/plugins/mstest/mstest-to-junit.xsl src/test/java/hudson/plugins/mstest/MSTestReportConverterTest.java src/test/resources/hudson/plugins/mstest/ JENKINS-25533 +19384.trx src/test/resources/hudson/plugins/mstest/ JENKINS-25533 +19384.xml src/test/resources/hudson/plugins/mstest/nilleb_HOST18468 2015-03-18 08_03_36.xml http://jenkins-ci.org/commit/mstest-plugin/2b6797a0cc004d7756bcb6d13fbba465389bdac2 Log: [FIXED JENKINS-25533] [FIXED JENKINS-19384] support for output/stdout messages

            mattmoor Matthew Moore
            podskalsky podskalsky
            Votes:
            6 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: