date:20191227

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jarred Parrett edited a comment on  JENKINS-59865  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bogus Scala Compiler warning about missing files after test failure in sbt   
 

  
 
 
 
 

 
 Thank you for the direction - it made it much easier to recreate. In working on it, I think its test class was SbtScalacParserTest.java; I ran that with a custom text file that contained the content from sbtScalac.txt with the addition of the above line. The test then fails as it expects 4 errors in the report but gets 5. To resolve this, I changed the SbtScalacParser.java to include the negative lookahead statement -{ { code:java} "^(\\[warn\\]|\\[error\\] (?!\\s+Total\\stime: ) ) \\s*(.*?):(\\d+)(?::\\d+)?:\\s*(.*)$" ; {code } }  Thank you for your help  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202604.1571658262000.530.1577462460192%40Atlassian.JIRA.

[JIRA] (JENKINS-59865) Bogus Scala Compiler warning about missing files after test failure in sbt

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jarred Parrett edited a comment on  JENKINS-59865  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bogus Scala Compiler warning about missing files after test failure in sbt   
 

  
 
 
 
 

 
 Thank you for the direction - it made it much easier to recreate. In working on it, I think its test class was SbtScalacParserTest.java; I ran that with a custom text file that contained the content from sbtScalac.txt with the addition of the above line. The test then fails as it expects 4 errors in the report but gets 5. To resolve this, I changed the SbtScalacParser.java to include the negative lookahead statement -{{ "^(\\[warn\\]|\\[error\\])\\s*(.*?):(\\d+)(?::\\d+)?:\\s*(.*)$";  }}  Thank you for your help  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202604.1571658262000.528.1577462400304%40Atlassian.JIRA.

[JIRA] (JENKINS-59865) Bogus Scala Compiler warning about missing files after test failure in sbt

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jarred Parrett edited a comment on  JENKINS-59865  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bogus Scala Compiler warning about missing files after test failure in sbt   
 

  
 
 
 
 

 
 Thank you for the direction - it made it much easier to recreate. In working on it, I think its test class was SbtScalacParserTest.java; I ran that with a custom text file that contained the content from sbtScalac.txt with the addition of the above line. The test then fails as it expects 4 errors in the report but gets 5. To resolve this, I changed the SbtScalacParser.java to include the negative lookahead statement -"^(\\[warn\\]|\\[error\\] +(?!\\s+Total\\stime: ) +) \\s*(.*?):(\\d+)(?::\\d+)?:\\s*(.*)$" ;    Thank you for your help  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202604.1571658262000.522.1577462340208%40Atlassian.JIRA.

[JIRA] (JENKINS-59865) Bogus Scala Compiler warning about missing files after test failure in sbt

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jarred Parrett commented on  JENKINS-59865  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bogus Scala Compiler warning about missing files after test failure in sbt   
 

  
 
 
 
 

 
 Thank you for the direction - it made it much easier to recreate. In working on it, I think its test class was SbtScalacParserTest.java; I ran that with a custom text file that contained the content from sbtScalac.txt with the addition of the above line. The test then fails as it expects 4 errors in the report but gets 5. To resolve this, I changed the SbtScalacParser.java to include the negative lookahead statement - "^(\\[warn\\]|\\[error\\](?!\\s+Totalstime)s*(.?)\\d+)(?::\\d+)?:s(.*)$"  Thank you for your help  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202604.1571658262000.518.1577462280208%40Atlassian.JIRA.

[JIRA] (JENKINS-60597) Break out AbstractProject-independent components of Promotion/PromotionProcess to new classes

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60597  
 
 
  Break out AbstractProject-independent components of Promotion/PromotionProcess to new classes   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 
 
Issue Type: 
 Task Improvement  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203819.1577458076000.516.1577458140105%40Atlassian.JIRA.

[JIRA] (JENKINS-60597) Break out AbstractProject-independent components of Promotion/PromotionProcess to new classes

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60597  
 
 
  Break out AbstractProject-independent components of Promotion/PromotionProcess to new classes   
 

  
 
 
 
 

 
Issue Type: 
  Task  
 
 
Assignee: 
 Oleg Nenashev  
 
 
Components: 
 promoted-builds-plugin  
 
 
Created: 
 2019-12-27 14:47  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Oleg Nenashev  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this

[JIRA] (JENKINS-57903) New PromotionProcess,PromotionCondition and PromotionConditionDescriptor classes for the plugin.

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57903  
 
 
  New PromotionProcess,PromotionCondition and PromotionConditionDescriptor classes for the plugin.   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 

  
 
 
 
 

 
 Before implementing the promotion-conditions(Self and Manual Conditions), it seems necessary to build new abstract/classes for the following existing classes. *  PromotionProcess *  PromotionCondition * PromotionConditionDescriptorFor readability ease all these classes are being added by the word "Pipeline" as their prefix.Three new analogous classes are being made retaining some of the original functions and will timely be updated as other classes start depending on them.Acceptance criteria: * The classes are created, and they can be used in further APIs. There is is no user-facing feature for now * The classes are marked as Restricted so that they not a part of API. It will change eventually * There is basic test automation that these classes really work   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[JIRA] (JENKINS-60591) checkout scm doesn't take revision that started the pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60591  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: checkout scm doesn't take revision that started the pipeline   
 

  
 
 
 
 

 
 I've confirmed the code behaves as described in a multibranch pipeline.  I'm not sure if the issue is in the git plugin or in the pipeline plugin that provides the configuration for the {{checkout scm}} step or in the use of the scm step.The test job that I created uses a scripted multibranch pipeline to wait 90 seconds before performing the first checkout.  During the 90 seconds while the job is waiting, another process pushes a new commit to the central repository.  The {{checkout scm}} step then runs and takes the new commit instead of taking the commit that provided the Jenkinsfile.Refer to the [verification job|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs].Declarative pipeline could likely create the same conditions by disabling default checkout. I haven't checked the behavior with pipelines that are not multibranch.   The documentation for the {{scm}} variable in a non-multibranch pipeline says:bq. Represents the SCM configuration in a multibranch project build. Use checkout scm to check out sources matching Jenkinsfile. You may also use this in a standalone project configured with Pipeline from SCM, though in that case the checkout will just be of the latest revision in the branch, possibly newer than the revision from which the Pipeline was loaded.I interpret that to mean that if you're expecting to get the version which matches the Jenkinsfile in a non-multibranch Pipeline, you will need to specifically request it.  I've confirmed that interpretation is correct.  When a pipeline that is not multibranch retrieves the Jenkinsfile from SCM using a lightweight checkout, it reports "Obtained Jenkinsfile from https://github.com/MarkEWaite/jenkins-bugs".  When it is not a lightweight checkout, it does not report 'Obtained Jenkinsfile' in the log at all.  When the same is done in a multibranch pipeline, it reports 'Obtained Jenkinsfile from '.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60596) PromotedBuildAction should implement the RunAction2Interface

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60596  
 
 
  PromotedBuildAction should implement the RunAction2Interface   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Oleg Nenashev  
 
 
Components: 
 promoted-builds-plugin  
 
 
Created: 
 2019-12-27 14:27  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Oleg Nenashev  
 

  
 
 
 
 

 
 If we want to make the plugin compatible with Jenkins Pipeline, we need to update the stored data accordingly  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[JIRA] (JENKINS-60596) PromotedBuildAction should implement the RunAction2Interface

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60596  
 
 
  PromotedBuildAction should implement the RunAction2Interface   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 
 
Issue Type: 
 Bug Improvement  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203818.1577456837000.508.1577456880208%40Atlassian.JIRA.

[JIRA] (JENKINS-60591) checkout scm doesn't take revision that started the pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60591  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: checkout scm doesn't take revision that started the pipeline   
 

  
 
 
 
 

 
 I've confirmed the code behaves as described in a multibranch pipeline.  I'm not sure if the issue is in the git plugin or in the pipeline plugin that provides the configuration for the {{checkout scm}} step or in the use of the scm step.The test job that I created uses a scripted multibranch pipeline to wait 90 seconds before performing the first checkout.  During the 90 seconds while the job is waiting, another process pushes a new commit to the central repository.  The {{checkout scm}} step then runs and takes the new commit instead of taking the commit that provided the Jenkinsfile.Refer to the [verification job|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs].Declarative pipeline could likely create the same conditions by disabling default checkout.I haven't checked the behavior with pipelines that are not multibranch.  The documentation for the {{scm}} variable in a non-multibranch pipeline says:bq. Represents the SCM configuration in a multibranch project build. Use checkout scm to check out sources matching Jenkinsfile. You may also use this in a standalone project configured with Pipeline from SCM, though in that case the checkout will just be of the latest revision in the branch, possibly newer than the revision from which the Pipeline was loaded.I interpret that to mean that if you're expecting to get the version which matches the Jenkinsfile in a non-multibranch Pipeline, you will need to specifically request it.  I've confirmed that interpretation is correct.  When a pipeline that is not multibranch retrieves the Jenkinsfile from SCM using a lightweight checkout, it reports "Obtained Jenkinsfile from  \ https://github.com/MarkEWaite/jenkins-bugs".  When it is not a lightweight checkout, it does not report 'Obtained Jenkinsfile' in the log at all.  When the same is done in a multibranch pipeline, it reports 'Obtained Jenkinsfile from '.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60591) checkout scm doesn't take revision that started the pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60591  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: checkout scm doesn't take revision that started the pipeline   
 

  
 
 
 
 

 
 I've confirmed the code behaves as described in a multibranch pipeline.  I'm not sure if the issue is in the git plugin or in the pipeline plugin that provides the configuration for the {{checkout scm}} step or in the use of the scm step.The test job that I created uses a scripted multibranch pipeline to wait 90 seconds before performing the first checkout.  During the 90 seconds while the job is waiting, another process pushes a new commit to the central repository.  The {{checkout scm}} step then runs and takes the new commit instead of taking the commit that provided the Jenkinsfile.Refer to the [verification job|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs].Declarative pipeline could likely create the same conditions by disabling default checkout.I haven't checked the behavior with pipelines that are not multibranch.  The documentation for the {{scm}} variable in a non-multibranch pipeline says:bq. Represents the SCM configuration in a multibranch project build. Use checkout scm to check out sources matching Jenkinsfile. You may also use this in a standalone project configured with Pipeline from SCM, though in that case the checkout will just be of the latest revision in the branch, possibly newer than the revision from which the Pipeline was loaded.I interpret that to mean that if you're expecting to get the version which matches the Jenkinsfile in a non-multibranch Pipeline, you will need to specifically request it.  I've confirmed that interpretation is correct.  When a pipeline that is not multibranch retrieves the Jenkinsfile from SCM using a lightweight checkout, it reports "Obtained Jenkinsfile from  \  https://github.com/MarkEWaite/jenkins-bugs".  When it is not a lightweight checkout, it does not report 'Obtained Jenkinsfile' in the log at all.  When the same is done in a multibranch pipeline, it reports 'Obtained Jenkinsfile from '.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60591) checkout scm doesn't take revision that started the pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60591  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: checkout scm doesn't take revision that started the pipeline   
 

  
 
 
 
 

 
 I've confirmed the code behaves as described in a multibranch pipeline.  I'm not sure if the issue is in the git plugin or in the pipeline plugin that provides the configuration for the {{checkout scm}} step or in the use of the scm step.The test job that I created uses a scripted multibranch pipeline to wait 90 seconds before performing the first checkout.  During the 90 seconds while the job is waiting, another process pushes a new commit to the central repository.  The {{checkout scm}} step then runs and takes the new commit instead of taking the commit that provided the Jenkinsfile.Refer to the [verification job|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs].Declarative pipeline could likely create the same conditions by disabling default checkout.I haven't checked the behavior with pipelines that are not multibranch.  The documentation for the {{scm}} variable in a non-multibranch pipeline says:bq. Represents the SCM configuration in a multibranch project build. Use checkout scm to check out sources matching Jenkinsfile. You may also use this in a standalone project configured with Pipeline from SCM, though in that case the checkout will just be of the latest revision in the branch, possibly newer than the revision from which the Pipeline was loaded.I interpret that to mean that if you're expecting to get the version which matches the Jenkinsfile in a non-multibranch Pipeline, you will need to specifically request it.   I've confirmed that interpretation is correct.  When a pipeline that is not multibranch retrieves the Jenkinsfile from SCM using a lightweight checkout, it reports "Obtained Jenkinsfile from https://github.com/MarkEWaite/jenkins-bugs".  When it is not a lightweight checkout, it does not report 'Obtained Jenkinsfile' in the log at all.  When the same is done in a multibranch pipeline, it reports 'Obtained Jenkinsfile from '.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60591) checkout scm doesn't take revision that started the pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60591  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: checkout scm doesn't take revision that started the pipeline   
 

  
 
 
 
 

 
 I've confirmed the code behaves as described  in a multibranch pipeline .  I'm not sure if the issue is in the git plugin or in the pipeline plugin that provides the configuration for the {{checkout scm}} step or in the use of the scm step.The test job that I created uses a scripted multibranch pipeline to wait 90 seconds before performing the first checkout.  During the 90 seconds while the job is waiting, another process pushes a new commit to the central repository.  The {{checkout scm}} step then runs and takes the new commit instead of taking the commit that provided the Jenkinsfile.Refer to the [verification job|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs].Declarative pipeline could likely create the same conditions by disabling default checkout.I haven't checked the behavior with pipelines that are not multibranch.  The documentation for the {{scm}} variable in a non-multibranch pipeline says:bq. Represents the SCM configuration in a multibranch project build. Use checkout scm to check out sources matching Jenkinsfile. You may also use this in a standalone project configured with Pipeline from SCM, though in that case the checkout will just be of the latest revision in the branch, possibly newer than the revision from which the Pipeline was loaded.I interpret that to mean that if you're expecting to get the version which matches the Jenkinsfile in a non-multibranch Pipeline, you will need to specifically request it.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[JIRA] (JENKINS-60595) Jenkins Multiple node to auto pick UFT test for execution serially

2019-12-27 Thread gsur...@ups.com (JIRA)

Title: Message Title

Govind Sureka created an issue

Jenkins / JENKINS-60595

Jenkins Multiple node to auto pick UFT test for execution serially

Issue Type:
Improvement

Assignee:
Maria Narcisa Galan

Components:
hp-application-automation-tools-plugin

Created:
2019-12-27 13:45

Environment:
Jenkins: CloudBees Enterprise jenkins ALM: 12.55 UFT: 14.03

Priority:
Major

Reporter:
Govind Sureka

Objective: Parallel execution of Test cases of UFT on different machines from one location of ALM. Current Situation:

We have 3 nodes available on CloudBees Jenkins for any job execution.
When we design any UFT Jenkins job, there we mention multiple nodes in the 'General' section.
In the Build section we are using plugin: Execute Micro Focus functional tests from Micro Focus ALM and mention the machine on which we want to execute the UFT test cases.
On triggering this job it will execute the UFT test cases on the mentioned machine using available node.
Improvement Expected: Want a way to specify multiple machines (workstation) in the build section of job so that Jenkins can pick 1 Test case on 1 machine and next test case on other available machine. The machines can node or any other mentioned machine. We want to have parallel execution of UFT test cases from 1 job so that if there are 10 Test cases and 10 machines are available then all should run in Parallel on different machines.

[JIRA] (JENKINS-57566) Default security prohibits ResultAction's getResult

2019-12-27 Thread ullrich.haf...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ulli Hafner commented on  JENKINS-57566  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Default security prohibits ResultAction's getResult   
 

  
 
 
 
 

 
 Since a couple of other users requested such a change I am reopening this issue. If we carefully decide which API methods should be made accessible, then we should manage it to make the API not vulnerable.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199480.1558369817000.492.1577452140117%40Atlassian.JIRA.

[JIRA] (JENKINS-57566) Default security prohibits ResultAction's getResult

2019-12-27 Thread ullrich.haf...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ulli Hafner reopened an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57566  
 
 
  Default security prohibits ResultAction's getResult   
 

  
 
 
 
 

 
Change By: 
 Ulli Hafner  
 
 
Resolution: 
 Won't Fix  
 
 
Status: 
 Resolved Reopened  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199480.1558369817000.490.1577452020442%40Atlassian.JIRA.

[JIRA] (JENKINS-60594) workflow-scm-step plugin does not use global credentials if used inside shared library

2019-12-27 Thread ulrich.lohrm...@dsv-gruppe.de (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ulrich Lohrmann closed an issue as Not A Defect  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 PEBKAC (Probelm exists between keyboard and chair).  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-60594  
 
 
  workflow-scm-step plugin does not use global credentials if used inside shared library   
 

  
 
 
 
 

 
Change By: 
 Ulrich Lohrmann  
 
 
Status: 
 Open Closed  
 
 
Resolution: 
 Not A Defect  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to

[JIRA] (JENKINS-60500) Break out the Promotion API plugin

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev commented on  JENKINS-60500  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Break out the Promotion API plugin   
 

  
 
 
 
 

 
 My plan is to do refactoring as a single plugin at the moment  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203591.1576499557000.487.1577450040141%40Atlassian.JIRA.

[JIRA] (JENKINS-60500) Break out the Promotion API plugin