date:20191209

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aish R created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60403  
 
 
  Unable to pass values to Matrix Combination Parameter using combination filter   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 matrix-combinations-parameter-plugin  
 
 
Created: 
 2019-12-09 13:01  
 
 
Labels: 
 combination_filter matrix_parameter_plugin  
 
 
Priority: 
  Blocker  
 
 
Reporter: 
 Aish R  
 

  
 
 
 
 

 
 how to pass different values to combination filter in matrix combination plugin. Say if I wanted my parent job to pass some values to downstream matrix parameter plugin using combination filter to just trigger all the failed ones again.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60013) Maven Artifact Repository Parameter fetches artifact from all the repositories mentioned in the global configuration.

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aish R started work on  JENKINS-60013  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Aish R  
 
 
Status: 
 Open In Progress  
 

  
 
 
 
 

 
 
 

 
 
 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.202834.1572594308000.2890.1575896640700%40Atlassian.JIRA.

[JIRA] (JENKINS-60013) Maven Artifact Repository Parameter fetches artifact from all the repositories mentioned in the global configuration.

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aish R stopped work on  JENKINS-60013  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Aish R  
 
 
Status: 
 In Progress Open  
 

  
 
 
 
 

 
 
 

 
 
 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.202834.1572594308000.2891.1575896640790%40Atlassian.JIRA.

[JIRA] (JENKINS-60403) Unable to pass values to Matrix Combination Parameter using combination filter

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aish R updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60403  
 
 
  Unable to pass values to Matrix Combination Parameter using combination filter   
 

  
 
 
 
 

 
Change By: 
 Aish R  
 

  
 
 
 
 

 
 how to pass different values to combination filter  shortcut link  in matrix combination plugin.Say if I wanted my parent job to pass some values to downstream matrix parameter plugin using combination filter to just trigger all the failed ones again.     
 

  
 
 
 
 

 
 
 

 
 
 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.203458.1575896493000.2897.1575896760072%40Atlassian.JIRA.

[JIRA] (JENKINS-60216) Pipeline Build Step should automatically convert mistyped parameters to the correct type where possible

2019-12-09 Thread smi...@smirky.net (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Bogomil Vasilev edited a comment on  JENKINS-60216  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Pipeline Build Step should automatically convert mistyped parameters to the correct type where possible   
 

  
 
 
 
 

 
 Hi, I just updated to the latest version (2.10) and I found out about this new improvement the hard way, via a few of our pipeline jobs, calling some downstream jobs.Until now, I was just doing something like this: {code:java}pipeline {parameters {choice(name: 'VAR_X', choices: ['1', '2', '3'], description: 'Pick something')string(name: 'VAR_Y', defaultValue: '', description: 'Specify Y') booleanParam(name: 'VAR_Z', defaultValue: false, description: 'True or False') choice(name: 'BUILD_PC', choices: ['bench1', 'bench2'], description: 'Specify a bench')} stages {  stage('Compile') {    when {_expression_ { params._ONLY_PACKAGES_ == false && params.NO_COVERITY == true  }    }    steps {catchError(buildResult: 'FAILURE', stageResult: 'FAILURE') { script {  result = build job: 'downstream_job', parameters: [   string(name: 'VAR_X', value: "${params.VAR_X}"),   string(name: 'VAR_Y', value: "${params.VAR_Y}",   string(name: 'VAR_Z', value: "${params.VAR_Z}",   // this is a Node variable in the downstream job   string(name: 'BUILD_PC', value: "${params.BUILD_PC}")  ]  } }}   }  } }}{code}I stumbled upon the new feature that told me that it's converting my string downstream input from string to boolean parameter. So I basically switched all the relevant string input variables to booleanParam(...), which resolved only that particular problem.However, I also have a Node input variable, which so far I was not able to resolve:{quote}The parameter 'BUILD_PC' did not have the type expected by downstream_job. Converting to Node.{quote}So it is obvious that I'm getting this error, because the Downstream job is using the "Node" variable via the "[Node and Label parameter plugin|https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin]".Thanks to the type conversion logic in the [pipeline-build-step-plugin|https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+pipeline-build-step-plugin], I don't have an actual downside from this and it just gives me the quoted warning above.Then again, I should somehow improve the expected type to be according to the downstream expectation.Giving it node() is simply not working, as it gives me a stacktrace.What is the correct way to fix this?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-59973) rtUpload / rtDownload fail with HTTP 401 / 403

Title: Message Title


 
 
 
 

 
 
 

 
   
 ethorsa commented on  JENKINS-59973  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: rtUpload / rtDownload fail with HTTP 401 / 403   
 

  
 
 
 
 

 
 Unfortunately I still run into the error using the attached snapshot version. I have setup a minimal example like this: Pipeline Code The pipeline code is integrated via multibranch pipeline (fetched from git repository). Beside the Git connection there's nothing configured in the multibranch pipeline project itself.   

 

pipeline {
agent any

stages {
stage("Test") {
steps {
rtDownload(serverId: 'artifactory-test', specPath: 'spec-dl.json')
}
}

}
}
 

   spec-dl.json: 

 

{
"files": [{
"pattern": "jenkins-artifactory-test/*",
"target": "jenkins-artifactory-test/",
"flat": "true"
}]
} 

   The git repository contains the Jenkinsfile and specfile. The job does not use folders – however, a multibranch pipeline itself is some kind of folder.   Artifactory repository The related artifactory repository jenkins-artifactory-test is of generic type and has permissions set, so all user can do anything. Anonymous user don't have access though. For this test it contains only a simple example.md file with some chars in it.   Jenkins Configuration The Artifactory connection is specified in the Jenkins global configuration (Artifactory section): 
 
Use the Credentials Plugin: yes 
Server ID: artifactory-test (as used in the pipeline) 
Default Deployer Credentials: 
 
Credentials: A credential stored by the credentials Plugin (Scope: Global, contains username and associated Artifactory API key) 
  
Use Different Resolver Credentials: no 
 Pressing the Test Connection button shows "Found Artifactory 6.12.2".   Running the Pipeline Executing the pipeline fails with following error (Blue Ocean, full log attached):   

 
Using spec file: \spec-dl.json

Searching for artifacts...

Failed to search artifact by the aql 'items.find({"repo": "jenkins-artifactory-test","$or": [{"$and": [{"path": { "$match": "*"},"name": { "$match": "*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")': HTTP/1.1 403
 

   There are no related entries in the global Jenkins All Log. Are there any logs that could b

[JIRA] (JENKINS-59973) rtUpload / rtDownload fail with HTTP 401 / 403

Title: Message Title


 
 
 
 

 
 
 

 
   
 ethorsa updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59973  
 
 
  rtUpload / rtDownload fail with HTTP 401 / 403   
 

  
 
 
 
 

 
Change By: 
 ethorsa  
 
 
Attachment: 
 artifactory-jenkins-log.log  
 

  
 
 
 
 

 
 
 

 
 
 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.202777.157235158.2906.1575897300625%40Atlassian.JIRA.

[JIRA] (JENKINS-59973) rtUpload / rtDownload fail with HTTP 401 / 403

Title: Message Title


 
 
 
 

 
 
 

 
   
 ethorsa updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59973  
 
 
  rtUpload / rtDownload fail with HTTP 401 / 403   
 

  
 
 
 
 

 
Change By: 
 ethorsa  
 
 
Attachment: 
 jenkins-artifactory-global-config.png  
 

  
 
 
 
 

 
 
 

 
 
 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.202777.157235158.2914.1575897660974%40Atlassian.JIRA.

[JIRA] (JENKINS-59973) rtUpload / rtDownload fail with HTTP 401 / 403

Title: Message Title


 
 
 
 

 
 
 

 
   
 ethorsa edited a comment on  JENKINS-59973  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: rtUpload / rtDownload fail with HTTP 401 / 403   
 

  
 
 
 
 

 
 Unfortunately I still run into the error using the attached snapshot version.I have setup a minimal example like this:h3. Pipeline CodeThe pipeline code is integrated via multibranch pipeline (fetched from git repository). Beside the Git connection there's nothing configured in the multibranch pipeline project itself. {code:java}pipeline {agent anystages {stage("Test") {steps {rtDownload(serverId: 'artifactory-test', specPath: 'spec-dl.json')}}}}{code} *spec-dl.json:*{code:java}{"files": [{"pattern": "jenkins-artifactory-test/*","target": "jenkins-artifactory-test/","flat": "true"}]}{code} The git repository contains the Jenkinsfile and specfile. The job does not use folders – however, a multibranch pipeline itself is some kind of folder. h3. Artifactory repositoryThe related artifactory repository _jenkins-artifactory-test_ is of generic type and has permissions set, so all user can do anything. Anonymous user don't have access though.For this test it contains only a simple _example.md_ file with some chars in it. h3. Jenkins ConfigurationThe Artifactory connection is specified in the _Jenkins global configuration_ (Artifactory section): - Use the Credentials Plugin: yes - Server ID: artifactory-test (as used in the pipeline) - Default Deployer Credentials: ** Credentials: A credential stored by the credentials Plugin (Scope: Global, contains username and associated Artifactory API key) - Use Different Resolver Credentials: noPressing the Test Connection button shows _"Found Artifactory 6.12.2"_.   Screenshot of the configuration attached. h3. Running the PipelineExecuting the pipeline fails with following error (Blue Ocean, full log attached): {noformat}Using spec file: \spec-dl.jsonSearching for artifacts...Failed to search artifact by the aql 'items.find({"repo": "jenkins-artifactory-test","$or": [{"$and": [{"path": { "$match": "*"},"name": { "$match": "*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")': HTTP/1.1 403{noformat} There are no related entries in the global Jenkins All Log. Are there any logs that could be helpful? h3. Versions * Jenkins: v2.190.3 *   * *  Artifactory Plugin: Snapshot by [~yahaviz] ** Credentials Plugin: 2.3.0 * Artifactory: 6.12.2    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60132) Add support for AWS parameter store as a backend for storing credentials

2019-12-09 Thread chris+jenk...@chriskilding.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Chris Kilding updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60132  
 
 
  Add support for AWS parameter store as a backend for storing credentials   
 

  
 
 
 
 

 
Change By: 
 Chris Kilding  
 

  
 
 
 
 

 
 *Feature*Allow Jenkins to look up credentials in AWS Parameter Store. (They will be stored as Secure String parameters [https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-securestring.html]).* Benefits Rationale *- Storing credentials in Parameter Store can be cheaper than storing them  in Secrets Manager. *Pitfalls* -  Secrets Manager may offer higher API rate limits or better QoS since it is a paid-for service. We would need to find out whether Parameter Store offers acceptable rate limits and performance for Jenkins to rely on.  TODO anything else? *Questions* - Does this belong in its own project/plugin or is there opportunity for code reuse as part of aws-secrets-manager-credentials-provider-plugin? -  Does Parameter Store offer acceptable API rate limits and QoS for Jenkins to rely on?-  Could we  reuse naming or storage conventions, such as tagging, that were defined when adding multiple  store all major  credential  support  types  ( JENKINS-58339 especially binary ones like the PKCS#12 certificate )  in Parameter Store ? *Constraints*- Jenkins should be able to source credentials from both Secrets Manager and Parameter Store. (Using one should not rule out using the other.)- If Jenkins encounters an error looking up secrets in one of the services, this should not impede lookups in the other. (An exception from a Secrets Manager API call should not break secret resolution in Parameter Store if PS is still functioning.)- Tag naming conventions should be shared in both PS and SM. (Eg a username tag should be called  {{  jenkins:credentials:username }}  in PS, just like it is in SM today.)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60053) Create null diff file on config history

2019-12-09 Thread robin.richard.sch...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Robin Schulz commented on  JENKINS-60053  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Create null diff file on config history   
 

  
 
 
 
 

 
 Hi, have you deactivated the "Do not save duplicate history" checkbox in global configuration?  
 

  
 
 
 
 

 
 
 

 
 
 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.202883.1572928345000.2924.1575899400575%40Atlassian.JIRA.

[JIRA] (JENKINS-60401) Consider merging secret-ssm into aws-secrets-manager

2019-12-09 Thread chris+jenk...@chriskilding.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Chris Kilding commented on  JENKINS-60401  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Consider merging secret-ssm into aws-secrets-manager   
 

  
 
 
 
 

 
 My coworker had an interesting take on this. He suggested that when he's writing a CasC YAML file and needs to specify a secret key for something, he would like the ability to reference a Jenkins credential's ID in the value slot, with some kind of interpolation syntax. The high level result would be that any credential, from any provider, could be used to fill in the secret value for that CasC entry.  
 

  
 
 
 
 

 
 
 

 
 
 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.203456.1575893716000.2928.1575899520422%40Atlassian.JIRA.

[JIRA] (JENKINS-60404) Warning exception after upgrading to Folders 6.10

2019-12-09 Thread michelzan...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Michel Zanini created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60404  
 
 
  Warning exception after upgrading to Folders 6.10   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Francisco Fernández  
 
 
Components: 
 cloudbees-folder-plugin  
 
 
Created: 
 2019-12-09 13:52  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Michel Zanini  
 

  
 
 
 
 

 
 Hi, After upgrading to the latest Folders plugin version, 6.10, I am getting a warning exception on the logs:   

 

2019-12-06 13:37:11.802+ [id=28]WARNING h.ExtensionFinder$GuiceFinder$FaultTolerantScope$1#error: Failed to instantiate Key[type=com.cloudbees.hudson.plugins.folder.config.AbstractFolderConfiguration, annotation=[none]]; skipping this component
com.google.inject.ProvisionException: Unable to provision, see the following errors:1) Tried proxying com.cloudbees.hudson.plugins.folder.config.AbstractFolderConfiguration to support a circular dependency, but it is not an interface.1 error
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:439)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:401)
at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:392)
at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:344)

[JIRA] (JENKINS-58353) New jenkins job doesn't get added to the Dashboard view using Python Jenkins

2019-12-09 Thread csanady.m...@ulyssys.hu (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Máté Csanády commented on  JENKINS-58353  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: New jenkins job doesn't get added to the Dashboard view using Python Jenkins   
 

  
 
 
 
 

 
 Hi Vineeth! Could you try it out? How did it go? Do sou need any help? Máté  
 

  
 
 
 
 

 
 
 

 
 
 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.200468.1562310678000.2933.1575899880397%40Atlassian.JIRA.

[JIRA] (JENKINS-60401) Consider merging secret-ssm into aws-secrets-manager

2019-12-09 Thread joseph...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Joseph Petersen commented on  JENKINS-60401  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Consider merging secret-ssm into aws-secrets-manager   
 

  
 
 
 
 

 
 Chris Kilding while your coworker idea is great. There will be a problem between configuring said provider and at the same time using that provider to reveal secrets. However this should be possible to solve to always configure credentials provider first and then have a secret resolver use the credentials provider  
 

  
 
 
 
 

 
 
 

 
 
 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.203456.1575893716000.2935.1575901500193%40Atlassian.JIRA.

[JIRA] (JENKINS-60397) Rebrand "Performance Center" product name to "LoadRunner Enterprise"

2019-12-09 Thread daniel.da...@hpe.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Daniel Danan edited a comment on  JENKINS-60397  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Rebrand "Performance Center" product name to "LoadRunner Enterprise"   
 

  
 
 
 
 

 
 [https://github.com/jenkinsci/hpe-application-automation-tools-plugin/pull/ 266 270 ]   
 

  
 
 
 
 

 
 
 

 
 
 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.203452.1575814038000.2936.1575902700086%40Atlassian.JIRA.

[JIRA] (JENKINS-59973) rtUpload / rtDownload fail with HTTP 401 / 403

2019-12-09 Thread yah...@jfrog.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Yahav Itzhak commented on  JENKINS-59973  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: rtUpload / rtDownload fail with HTTP 401 / 403   
 

  
 
 
 
 

 
 ethorsa, Unfortunately, I didn't manage to reproduce your issue. I ran this project https://github.com/yahavi/jenkins-reproducer in multibranch pipeline and it worked. Credentials plugin and Artifactory version as yours. "Allow Anonymous Access" is not checked. I used this docker image for artifactory: https://bintray.com/jfrog/reg2/jfrog%3Aartifactory-oss/6.12.2 Repository: generic-local   Please look at Artifactory logs, specifically you need the access.log. You can access Artifactory logs from the UI: https://www.jfrog.com/confluence/display/RTF/Artifactory+Log+Files#ArtifactoryLogFiles-ViewingLogFilesfromtheUI Looking forward for your feedback!  
 

  
 
 
 
 

 
 
 

 
 
 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.202777.157235158.2939.1575903240506%40Atlassian.JIRA.

[JIRA] (JENKINS-59973) rtUpload / rtDownload fail with HTTP 401 / 403

2019-12-09 Thread ey...@jfrog.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Eyal Ben Moshe commented on  JENKINS-59973  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: rtUpload / rtDownload fail with HTTP 401 / 403   
 

  
 
 
 
 

 
 To narrow down the possible root cause of the issue, can you please try sending this AQL to Artifactory using curl? If you get a 403 response using curl as well, we can take Jenkins out of the equation, and focus on why Artifactory rejects this request.   
 

  
 
 
 
 

 
 
 

 
 
 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.202777.157235158.2946.1575903300418%40Atlassian.JIRA.

[JIRA] (JENKINS-60352) Ansible Tower Plugin does not pass credentials from job to Ansible tower 3.6.1

2019-12-09 Thread kyle.fat...@gmail.com (JIRA)

Title: Message Title

kyle fattig commented on JENKINS-60352

Re: Ansible Tower Plugin does not pass credentials from job to Ansible tower 3.6.1

Lili Wang That was the change I tried initially, but 'credentials' takes a list while 'credential' takes a list so tower throws a type error. That's jist of the issue though - Tower 3.6 removed the 'credential' field which is what the plugin sends. Here's the smallest change I could make that seems to work for now. There's already logic in place to account for this, it just needs to be used. Note this will break compatibility with old versions of the API that don't support 'credentials' field. We built this code and are using it for now as a stop-gap since Tower 3.6 supports only 'credentials': https://github.com/jenkinsci/ansible-tower-plugin/compare/master...kfattig:master John Westcott I believe this code segment needs to be revisited. The comment explains the logic, but I believe it's flawed. Tower only accepts 1 machine credential currently, so 'if' statement is never entered. Since the accepted fields change based on the API version - maybe that should be taken into account here instead? Happy to contribute or test as necessary, just didn't feel confident submitting a full PR without more information & testing.

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

[JIRA] (JENKINS-60352) Ansible Tower Plugin does not pass credentials from job to Ansible tower 3.6.1

2019-12-09 Thread kyle.fat...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 kyle fattig edited a comment on  JENKINS-60352  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Ansible Tower Plugin does not pass credentials from job to Ansible tower 3.6.1   
 

  
 
 
 
 

 
 [~clover1983] That was the change I tried initially, but 'credentials' takes a list while 'credential' takes  a list  an int  so tower throws a type error. That's jist of the issue though - Tower 3.6 removed the 'credential' field which is what the plugin sends. Here's the smallest change I could make that seems to work for now. There's already logic in place to account for this, it just needs to be used. Note this will break compatibility with old versions of the API that don't support 'credentials' field. We built this code and are using it for now as a stop-gap since Tower 3.6 supports only 'credentials':[https://github.com/jenkinsci/ansible-tower-plugin/compare/master...kfattig:master] [~johnwestcottiv] I believe [this code segment|https://github.com/jenkinsci/ansible-tower-plugin/blob/ea9541646df260ac7ca4c8c626867c96419f2751/src/main/java/org/jenkinsci/plugins/ansible_tower/util/TowerConnector.java#L499-L526] needs to be revisited. The comment explains the logic, but I believe it's flawed. Tower only accepts 1 machine credential currently, so 'if' statement is never entered. Since the accepted fields change based on the API version - maybe that should be taken into account here instead? Happy to contribute or test as necessary, just didn't feel confident submitting a full PR without more information & testing.  
 

  
 
 
 
 

 
 
 

 
 
 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.
T

[JIRA] (JENKINS-60352) Ansible Tower Plugin does not pass credentials from job to Ansible tower 3.6.1

2019-12-09 Thread kyle.fat...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 kyle fattig edited a comment on  JENKINS-60352  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Ansible Tower Plugin does not pass credentials from job to Ansible tower 3.6.1   
 

  
 
 
 
 

 
 [~clover1983] That was the change I tried initially, but 'credentials' takes a list while 'credential' takes an int so tower throws a type error. That's jist of the issue though - Tower 3.6 removed the 'credential' field which is what the plugin sends. Here's the smallest change I could make that seems to work for now. There's already logic in place to account for this, it just needs to be used. Note this will break compatibility with old versions of the API that don't support 'credentials' field. We built this code and are using it for now as a stop-gap since Tower 3.6 supports only 'credentials': [https://github.com/jenkinsci/ansible-tower-plugin/compare/master...kfattig:master] [~johnwestcottiv] I believe [this code segment|https://github.com/jenkinsci/ansible-tower-plugin/blob/ea9541646df260ac7ca4c8c626867c96419f2751/src/main/java/org/jenkinsci/plugins/ansible_tower/util/TowerConnector.java#L499-L526] needs to be revisited. The comment explains the logic, but I believe it's flawed. Tower only accepts 1 machine credential currently, so  the  'if' statement is never entered. Since the accepted fields change based on the API version - maybe that should be taken into account here instead? Happy to contribute or test as necessary, just didn't feel confident submitting a full PR without more information & testing.  
 

  
 
 
 
 

 
 
 

 
 
 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 u

[JIRA] (JENKINS-60216) Pipeline Build Step should automatically convert mistyped parameters to the correct type where possible

2019-12-09 Thread dnusb...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devin Nusbaum commented on  JENKINS-60216  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Pipeline Build Step should automatically convert mistyped parameters to the correct type where possible   
 

  
 
 
 
 

 
 Bogomil Vasilev In all cases, your builds continued working, right? The problem was just that you started to see a warning telling you that the parameter types were mismatched? Or did the builds where the downstream job was a node parameter start failing? If your builds where the downstream job was using a node parameter were working before the fix, then maybe you could just switch the downstream job to have a string parameter instead (which would match the behavior from before this change would made), and if the builds started failing after the fix, then that is definitely what you should do. Otherwise, you can safely ignore the message in the build logs (maybe we could add a way to suppress the conversion messages if that is important). As far as the right syntax to use so that no conversion is needed, it looks like Node and Label Parameter Plugin does not support Pipeline syntax natively (there is no symbol like "node" or "nodeParam" or anything), and perhaps there are other bugs that make it not work correctly (see PR 14, not sure what that is about), and it has some bug that makes the explicit data binding syntax not work either (JENKINS-47571), so I'm not totally sure how to use it correctly from Pipeline.  
 

  
 
 
 
 

 
 
 

 
 
 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 jen

[JIRA] (JENKINS-60405) Owner 'xyz' is neither a user/group/subgroup

2019-12-09 Thread b...@oostdesign.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Oost created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60405  
 
 
  Owner 'xyz' is neither a user/group/subgroup   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Parichay Barpanda  
 
 
Components: 
 gitlab-branch-source-plugin  
 
 
Created: 
 2019-12-09 15:30  
 
 
Labels: 
 configuration plugin jenkins  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 Bert Oost  
 

  
 
 
 
 

 
 Hi, I am getting this error since a while. This is the trace of the error; Using Jenkins 2.190.3 Plugin version 1.4.1 I have setupped an access token on gitlab.com and using it as username/password credentials. And I also tried ssh key credentials, but that didn't work either. It worked before. 

 

java.lang.IllegalStateException: Owner 'xyz' is neither a user/group/subgroup
	at io.jenkins.plugins.gitlabbranchsource.helpers.GitLabOwner.fetchOwner(GitLabOwner.java:39)
	at io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator$DescriptorImpl.doCheckProjectOwner(GitLabSCMNavigator.java:429)
	at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:396)
	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:408)
	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:212)
	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:145)
	at org.kohsuke.stapler.MetaClass$11.doDispatch(MetaClass.java:535)
	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:747)
	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:878)
	at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:280)
	at org

[JIRA] (JENKINS-40986) Matrix structure for Declarative Pipeline

2019-12-09 Thread simlarou...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Simon Larouche-Gagne commented on  JENKINS-40986  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Matrix structure for Declarative Pipeline   
 

  
 
 
 
 

 
 +1 on the exclude syntax, it's taking a lot of space. Also, can the values field of the axis block be dynamic instead of using a filter parameter? I have a use case with axes with a lot of values depending on a parameter, so if I can't act on the matrix values, my only option is to handle it in a when block? Also, in most cases, I would rather use a global variable to store my axes values as well, makes it easier to maintain and I could re-use it in another matrix block further down in the script. But overall I'm very happy to see a matrix block in declarative pipeline.  
 

  
 
 
 
 

 
 
 

 
 
 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.177717.1484126711000.2995.1575905820818%40Atlassian.JIRA.

[JIRA] (JENKINS-60406) Deprecate Jenkins.RUN_SCRIPTS, PluginManager.UPLOAD_PLUGINS, & PluginManager.CONFIGURE_UPDATECENTER

2019-12-09 Thread mikeciri...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 mike cirioli created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60406  
 
 
  Deprecate Jenkins.RUN_SCRIPTS, PluginManager.UPLOAD_PLUGINS, & PluginManager.CONFIGURE_UPDATECENTER   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 mike cirioli  
 
 
Components: 
 core  
 
 
Created: 
 2019-12-09 16:03  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 mike cirioli  
 

  
 
 
 
 

 
 Flag the following permission types as @Deprecated:  
 
Jenkins.RUN_SCRIPTS 
PluginManager.UPLOAD_PLUGINS 
PluginManager.CONFIGURE_UPDATECENTER 
 The usage of these permissions is confusing, and has been effectively hidden (unless specifically enabled) since 2017-4-10.   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60406) Deprecate Jenkins.RUN_SCRIPTS, PluginManager.UPLOAD_PLUGINS, & PluginManager.CONFIGURE_UPDATECENTER

2019-12-09 Thread mikeciri...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 mike cirioli updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60406  
 
 
  Deprecate Jenkins.RUN_SCRIPTS, PluginManager.UPLOAD_PLUGINS, & PluginManager.CONFIGURE_UPDATECENTER   
 

  
 
 
 
 

 
Change By: 
 mike cirioli  
 

  
 
 
 
 

 
 Flag the following permission types as {{@Deprecated}}: * {{Jenkins.RUN_SCRIPTS}} * {{PluginManager.UPLOAD_PLUGINS}} * {{PluginManager.CONFIGURE_UPDATECENTER}} The usage of these permissions is confusing, and has been effectively hidden (unless specifically enabled) since  [ 2017-4-10 |  ( https://jenkins.io/security/advisory/2017-04-10/#matrix-authorization-strategy-plugin-allowed-configuring-dangerous-permissions ] ) .   
 

  
 
 
 
 

 
 
 

 
 
 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-issu

[JIRA] (JENKINS-58783) Update pipeline stage-view-plugin to use the new WarningAction API

2019-12-09 Thread tobias-jenk...@23.gs (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tobias Gruetzmacher commented on  JENKINS-58783  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Update pipeline stage-view-plugin to use the new WarningAction API   
 

  
 
 
 
 

 
 It seems this is only a display problem: See https://github.com/jenkinsci/pipeline-stage-view-plugin/pull/80 for a possible fix.  
 

  
 
 
 
 

 
 
 

 
 
 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.201093.156474881.3052.1575908041396%40Atlassian.JIRA.

[JIRA] (JENKINS-60393) cloudbees-folder circular dependency

2019-12-09 Thread rob.ech...@solace.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rob Echlin commented on  JENKINS-60393  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: cloudbees-folder circular dependency   
 

  
 
 
 
 

 
 My Jenkins would not start, and had this error. I reverted all of my changed plugins, including cloudbees-folder, and I was able to start Jenkins. I will try with just this plugin kept back to 6.9, and updating all the others, sometime soon.  
 

  
 
 
 
 

 
 
 

 
 
 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.203447.1575664332000.3056.1575909480221%40Atlassian.JIRA.

[JIRA] (JENKINS-56286) Multibranch Pipeline + P4Plugin + Helix Library + Polling = Infinite Build Loop

2019-12-09 Thread kwi...@perforce.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Karl Wirth assigned an issue to Karl Wirth  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-56286  
 
 
  Multibranch Pipeline + P4Plugin + Helix Library + Polling = Infinite Build Loop   
 

  
 
 
 
 

 
Change By: 
 Karl Wirth  
 
 
Assignee: 
 Kevin Williamson Karl Wirth  
 

  
 
 
 
 

 
 
 

 
 
 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.197865.1551180689000.3061.1575909540241%40Atlassian.JIRA.

[JIRA] (JENKINS-58783) Update pipeline stage-view-plugin to use the new WarningAction API

2019-12-09 Thread jonhat...@faita.net (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jonathan Araña Cruz commented on  JENKINS-58783  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Update pipeline stage-view-plugin to use the new WarningAction API   
 

  
 
 
 
 

 
 great! it was quite easy!  
 

  
 
 
 
 

 
 
 

 
 
 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.201093.156474881.3066.1575910200507%40Atlassian.JIRA.

[JIRA] (JENKINS-60393) cloudbees-folder circular dependency

2019-12-09 Thread rob.ech...@solace.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rob Echlin edited a comment on  JENKINS-60393  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: cloudbees-folder circular dependency   
 

  
 
 
 
 

 
 My Jenkins  LTS  would not start, and had this error.I reverted all of my changed plugins, including cloudbees-folder, and I was able to start Jenkins.I will try with just this plugin kept back to 6.9, and updating all the others, sometime soon.  
 

  
 
 
 
 

 
 
 

 
 
 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.203447.1575664332000.3087.1575910620218%40Atlassian.JIRA.

[JIRA] (JENKINS-60407) Launched instances cannot reach public internet (regression)

2019-12-09 Thread james.mk.gr...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 James Green created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60407  
 
 
  Launched instances cannot reach public internet (regression)   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 FABRIZIO MANFREDI  
 
 
Components: 
 ec2-plugin  
 
 
Created: 
 2019-12-09 17:03  
 
 
Environment: 
 Jenkins ver. 2.190.3  
 
 
Priority: 
  Major  
 
 
Reporter: 
 James Green  
 

  
 
 
 
 

 
 With plugin 1.45 all is working. Upgraded to 1.46.1 and although the agents report themselves as available, they have no network access to the outside world. Reverting to 1.45 got them back again. The agents are each configured with the same single private subnet to launch into. Investigations showed things like `ping -c 3 google.com` times out. Checking out from bitbucket.org was the original fault reported. We have apparently made no changes to the Jenkins master, except to upgrade it to the current LTS from a recent release at the same time as updating the plugins this lunchtime.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-51552) Cannot replay pipelines - files are read-only

2019-12-09 Thread kwi...@perforce.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Karl Wirth commented on  JENKINS-51552  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot replay pipelines - files are read-only   
 

  
 
 
 
 

 
 Hi Erez Arbell - Thanks but in the last data you sent me the definition for the function 'LoadLibrary' in your code included 'retriever: legacySCM'. Please check if that function still uses 'retriever: legacySCM' and try it with 'retriever: modernSCM'. Thanks in advance, Karl  
 

  
 
 
 
 

 
 
 

 
 
 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.190940.1527360591000.3099.1575911160277%40Atlassian.JIRA.

[JIRA] (JENKINS-60408) Workspace Volume configuration not being used

2019-12-09 Thread neil.r.green+jenk...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Neil Green created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60408  
 
 
  Workspace Volume configuration not being used   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 kubernetes-plugin  
 
 
Created: 
 2019-12-09 17:36  
 
 
Environment: 
 Jenkins ver. 2.190.3  Kubernetes Plugin 1.21.4  Kubernetes 1.14.8-eks  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Neil Green  
 

  
 
 
 
 

 
 I have configured a Dynamic PVC Workspace volume through the jenkins ui. It's not being picked up by the build pods from a Jenkins declarative pipeline. I've checked what's in config.xml and this block has been created:  {{}} 

 

"org.csanchez.jenkins.plugins.kubernetes.volumes.workspace.DynamicPVCWorkspaceVolume">
 gp2
 30Gi
 ReadWriteOnce
  

 {{}} The storage class gp2 exists in the cluster and its provisioner is kubernetes.io/aws-ebs. It has been used to provision other  For debugging purposes, I've tried different workspace volume settings, including different classes (e.g. NFS, Host Path), but none of them have any effect. Regardless of the configuration the build always outputs: {{}} 

 

volumes:
  - configMap:
  name: "qb-build-m2"
    name: "m2"
  - emptyDir:
  medium: ""
    name: "workspace-volume"
 
 

 The configMap volume comes from the

[JIRA] (JENKINS-60393) cloudbees-folder circular dependency

2019-12-09 Thread rob.ech...@solace.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rob Echlin commented on  JENKINS-60393  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: cloudbees-folder circular dependency   
 

  
 
 
 
 

 
 I was able to catch that Jenkins server with only one job, and only a few minutes left. When I updated all my plugins except cloudbees-folder, Jenkins restarted with no visible issues. Looks like it really was cloudbees-folder that was blocking our server from starting.  
 

  
 
 
 
 

 
 
 

 
 
 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.203447.1575664332000.3121.1575915602868%40Atlassian.JIRA.

[JIRA] (JENKINS-51552) Cannot replay pipelines - files are read-only

2019-12-09 Thread e...@arbell.co.il (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Erez Arbell commented on  JENKINS-51552  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot replay pipelines - files are read-only   
 

  
 
 
 
 

 
 I changed "legacySCM" to "modernSCM" and got error:   

 

java.lang.UnsupportedOperationException: no known implementation of class jenkins.scm.api.SCMSource is named PerforceScm
... 

 I tried "Helix Library", using the Snippet Generator:     

 

def p4Mapping = "//depot/project/automation/jenkins/pipeline/src/com/v4/...\n" +
   "//depot/project/automation/jenkins/pipeline/vars/..."
def lib = library identifier: args.identifier, retriever: modernSCM(globalLib(charset: 'none', path: p4Mapping, credential: env.P4_CREDENTIAL))
 

 and got this error:     

 

 (p4):cmd:... p4 sync -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...#none
 p4 sync -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...#none
 
 (p4):stop:9
 ... rm -rf /home/jenkins/.jenkins/workspace/test-p4@libs
 
 P4 Task: syncing files at change: -1
 (p4):cmd:... p4 sync -f -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...@-1
 p4 sync -f -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...@-1
 
 Invalid changelist/client/label/date '@-1'.
 
 (p4):stop:10
 P4 Task: attempt: 1
 ERROR: P4: Task Exception: com.perforce.p4java.exception.P4JavaException: com.perforce.p4java.exception.P4JavaException: hudson.AbortException: P4JAVA: Error(s):
 Invalid changelist/client/label/date '@-1'.
 

 What is the syntax to use? I did not find it documented.    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-51552) Cannot replay pipelines - files are read-only

2019-12-09 Thread e...@arbell.co.il (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Erez Arbell edited a comment on  JENKINS-51552  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot replay pipelines - files are read-only   
 

  
 
 
 
 

 
 I changed "legacySCM" to "modernSCM" and got error:   {code:java}java.lang.UnsupportedOperationException: no known implementation of class jenkins.scm.api.SCMSource is named PerforceScm...{code}I tried "Helix Library", using the Snippet Generator:    {code:java}def p4Mapping = "//depot/project/automation/jenkins/pipeline/src/com/v4/...\n" +   "//depot/project/automation/jenkins/pipeline/vars/..."def lib = library identifier: args.identifier, retriever: modernSCM(globalLib(charset: 'none', path: p4Mapping, credential: env.P4_CREDENTIAL)){code}and got this error:    {code:java} (p4):cmd:... p4 sync -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...#none p4 sync -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...#none  (p4):stop:9 ... rm -rf /home/jenkins/.jenkins/workspace/test-p4@libs  P4 Task: syncing files at change: -1 (p4):cmd:... p4 sync -f -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...@-1 p4 sync -f -q /home/jenkins/.jenkins/workspace/test-p4%40libs/...@-1  Invalid changelist/client/label/date '@-1'.  (p4):stop:10 P4 Task: attempt: 1 ERROR: P4: Task Exception: com.perforce.p4java.exception.P4JavaException: com.perforce.p4java.exception.P4JavaException: hudson.AbortException: P4JAVA: Error(s): Invalid changelist/client/label/date '@-1'.{code}What is the syntax to use? I did not find it documented.    
 

  
 
 
 
 

 
 
 

 
 
 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

[JIRA] (JENKINS-60409) Cloud Configuration Length Cap

2019-12-09 Thread mastershihochief...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Joshua Hunter created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60409  
 
 
  Cloud Configuration Length Cap   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 Screen Shot 2019-12-09 at 10.21.53 AM.png  
 
 
Components: 
 core  
 
 
Created: 
 2019-12-09 18:25  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Joshua Hunter  
 

  
 
 
 
 

 
 In Jenkins Version 2.205, PR #4339 moved the cloud configuration from Configure System into is own configuration form on the Manage Nodes page. There is a cap to the length of this form (20) and prevents me from adding additional docker clouds into the settings. 

 

java.lang.IllegalStateException: Form is larger than max length 20
	at org.eclipse.jetty.server.Request.extractFormParameters(Request.java:562)
	at org.eclipse.jetty.server.Request.extractContentParameters(Request.java:519)
	at org.eclipse.jetty.server.Request.getParameters(Request.java:430)
Caused: org.eclipse.jetty.http.BadMessageException: 400: Unable to parse form content
	at org.eclipse.jetty.server.Request.getParameters(Request.java:434)
	at org.eclipse.jetty.server.Request.getParameterNames(Request.java:1077)
	at hudson.security.csrf.CrumbFilter.extractCrumbFromRequest(CrumbFilter.java:112)
	at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:81)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
	at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
	at jenkins.security.ExceptionTra

[JIRA] (JENKINS-60405) Owner 'xyz' is neither a user/group/subgroup

2019-12-09 Thread b...@oostdesign.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Oost commented on  JENKINS-60405  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Owner 'xyz' is neither a user/group/subgroup   
 

  
 
 
 
 

 
 It works when using my Gitlab username as owner, but not when using one of my groups (which worked before)  
 

  
 
 
 
 

 
 
 

 
 
 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.203460.1575905424000.3130.1575916440129%40Atlassian.JIRA.

[JIRA] (JENKINS-60406) Deprecate Jenkins.RUN_SCRIPTS, PluginManager.UPLOAD_PLUGINS, & PluginManager.CONFIGURE_UPDATECENTER

2019-12-09 Thread mikeciri...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 mike cirioli started work on  JENKINS-60406  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 mike cirioli  
 
 
Status: 
 Open In Progress  
 

  
 
 
 
 

 
 
 

 
 
 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.203461.1575907415000.3131.1575916920113%40Atlassian.JIRA.

[JIRA] (JENKINS-60410) Suppress stack traces in core

2019-12-09 Thread jthomp...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jeff Thompson created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60410  
 
 
  Suppress stack traces in core   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Jeff Thompson  
 
 
Components: 
 core  
 
 
Created: 
 2019-12-09 18:53  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Jeff Thompson  
 

  
 
 
 
 

 
 I propose to move the capability from the Suppress Stack Trace Plugin into core and clean it up a little bit. The existing plugin behavior is to show the trace to administrators and to connect it to a specific log message for other users. I propose to retain this behavior. Jenkins has seen a significant rise in security-conscious use since this plugin was created. Jenkins should be more secure by default. While showing the stack trace isn't a security vulnerability, not showing the trace is standard, expected industry behavior.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60411) Tried proxying com.cloudbees.hudson.plugins.folder.config.AbstractFolderConfiguration to support a circular dependency, but it is not an interface.

2019-12-09 Thread jp_ab...@id.uff.br (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 João Pedro Abreu de Souza created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60411  
 
 
  Tried proxying com.cloudbees.hudson.plugins.folder.config.AbstractFolderConfiguration to support a circular dependency, but it is not an interface.   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Andrew Bayer  
 
 
Components: 
 pipeline-model-definition-plugin  
 
 
Created: 
 2019-12-09 18:57  
 
 
Environment: 
 Jenkins 2.207, pipeline-model-definition 1.5.0, ubuntu sub-system 18.04 on Windows 10  
 
 
Priority: 
  Blocker  
 
 
Reporter: 
 João Pedro Abreu de Souza  
 

  
 
 
 
 

 
 When I try to add pipeline-model-definition on version 1.5.0, the message on summary show. Can see this problem on a pure environment on github.com/petrolifero/jenkinsDocker, branch bug/pipeline-mr.  Just execute run.sh  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60354) Updated pipeline build step does not work with retry, catchError, or warnError

2019-12-09 Thread m...@basilcrow.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Basil Crow commented on  JENKINS-60354  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Updated pipeline build step does not work with retry, catchError, or warnError   
 

  
 
 
 
 

 
 It might be worth considering the use case in JENKINS-51454 as part of the design of this solution.  
 

  
 
 
 
 

 
 
 

 
 
 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.203371.1575392042000.3136.1575919140185%40Atlassian.JIRA.

[JIRA] (JENKINS-51454) Pipeline retry operation doesn't retry when there is a timeout inside of it

2019-12-09 Thread dnusb...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devin Nusbaum commented on  JENKINS-51454  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Pipeline retry operation doesn't retry when there is a timeout inside of it   
 

  
 
 
 
 

 
 I think there are two desired behaviors depending on the placement of timeout and retry relative to each other. First case (this ticket): 

 

retry(3) {
  timeout(time: 5, unit: 'MINUTES') {
// Something that can fail
  }
}
 

 In this case, if the timeout triggers, I think the desired behavior is for retry to run its body again. This is not the current behavior. Second case (not this ticket): 

 

timeout(time: 5, unit: 'MINUTES') {
  retry(3) {
// Something that can fail
  }
}
 

 In this case, if the timeout triggers, I think the desired behavior is for retry to be aborted without retrying anything. This is the current behavior, and as far as I understand, is working as-designed after JENKINS-44379. Switching timeout to use a different kind of exception would fix the first case, but break the second case. To support both use cases, something more complex would be needed (see PR 81 for a possible approach, although retry would need to be updated as well)). Basil Crow Noted that a fix for JENKINS-60354 might overlap a bit with this issue.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60354) Updated pipeline build step does not work with retry, catchError, or warnError

2019-12-09 Thread dnusb...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devin Nusbaum commented on  JENKINS-60354  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Updated pipeline build step does not work with retry, catchError, or warnError   
 

  
 
 
 
 

 
 Basil Crow Good point, I commented on that ticket. I think that the approach from this PR could be tweaked a bit to use https://github.com/jenkinsci/workflow-step-api-plugin/pull/51 (if a setter was added) to change the value of FlowInterruptedException.actualInterruption from true to false when the exception propagates past the timeout step that threw the exception, in which case the fix for this issue would fix that issue as well.  
 

  
 
 
 
 

 
 
 

 
 
 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.203371.1575392042000.3153.1575920580164%40Atlassian.JIRA.

[JIRA] (JENKINS-57232) Configuration as code support for audit-trail plugin

2019-12-09 Thread pibe...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Pierre Beitz updated  JENKINS-57232  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57232  
 
 
  Configuration as code support for audit-trail plugin   
 

  
 
 
 
 

 
Change By: 
 Pierre Beitz  
 
 
Status: 
 Fixed but Unreleased Resolved  
 

  
 
 
 
 

 
 
 

 
 
 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.198992.1556571471000.3157.1575921180589%40Atlassian.JIRA.

[JIRA] (JENKINS-57232) Configuration as code support for audit-trail plugin

2019-12-09 Thread pibe...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Pierre Beitz updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57232  
 
 
  Configuration as code support for audit-trail plugin   
 

  
 
 
 
 

 
Change By: 
 Pierre Beitz  
 
 
Labels: 
 3.0-fixed jcasc-compatibility  
 

  
 
 
 
 

 
 
 

 
 
 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.198992.1556571471000.3161.1575921240215%40Atlassian.JIRA.

[JIRA] (JENKINS-60394) Can't load http://localhost:8080

2019-12-09 Thread jorgecordob...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jorge Cordoba assigned an issue to Jorge Cordoba  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60394  
 
 
  Can't load http://localhost:8080
 

  
 
 
 
 

 
Change By: 
 Jorge Cordoba  
 
 
Assignee: 
 Jorge Cordoba  
 

  
 
 
 
 

 
 
 

 
 
 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.203448.1575669122000.3165.1575925260295%40Atlassian.JIRA.

[JIRA] (JENKINS-60394) Can't load http://localhost:8080

2019-12-09 Thread jorgecordob...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jorge Cordoba commented on  JENKINS-60394  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Can't load http://localhost:8080
 

  
 
 
 
 

 
 Hello Martino Holus, can you tell me what happens if you run this  

 

mvn -am -pl war,bom -DskipTests -Dspotbugs.skip clean install 

 instead of  

 

java -jar jenkins.war
 

 According to the [CONTRIBUTING.md|https://github.com/jenkinsci/jenkins/blob/master/CONTRIBUTING.md] file, that should be the command executed to run Jenkins with a .war file without running tests. Let me know if this fixes the problem.    
 

  
 
 
 
 

 
 
 

 
 
 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.203448.1575669122000.3167.1575925620306%40Atlassian.JIRA.

[JIRA] (JENKINS-60412) Additional behavior "Discover open changes" not working for using Gerrit as SCM in Jenkins Shared Library configuration

Title: Message Title

Felipe Santos created an issue

Jenkins / JENKINS-60412

Additional behavior "Discover open changes" not working for using Gerrit as SCM in Jenkins Shared Library configuration

Issue Type:
Bug

Assignee:
Luca Domenico Milanesio

Components:
gerrit-code-review-plugin

Created:
2019-12-09 21:24

Environment:
gerrit-code-review-plugin 0.3.7 Jenkins 2.190.3 Gerrit 2.14.20

Priority:
Minor

Reporter:
Felipe Santos

This plugin adds Gerrit as SCM. However, for using Gerrit as the SCM for configuring a Jenkins Shared Library, the additional behavior "Discover open changes" isn't working. How to replicate: Go to Manage Jenkins, click on Configure System. Scroll down to Global Pipeline Libraries. Configure everything as usual, select Gerrit for Source Code Management. You might take note that by default the Additional behavior "Discover open changes" comes. However, if you try to run a pipeline using a version of the library that is not merged yet (open change), Jenkins won't be able to fetch or locate that revision (the version is identified by the Git commit hash). Workaround: Since the option "Discover open changes doesn't work, you can delete it. On the additional behavior "Specify ref specs", add one and put the value: +refs/changes/:refs/changes/ Now, if you try to run a pipeline specifying a version not merged yet, Jenkins will be able to fetch it.

[JIRA] (JENKINS-60394) Can't load http://localhost:8080

2019-12-09 Thread jorgecordob...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jorge Cordoba started work on  JENKINS-60394  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Jorge Cordoba  
 
 
Status: 
 Open In Progress  
 

  
 
 
 
 

 
 
 

 
 
 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.203448.1575669122000.3173.1575927000171%40Atlassian.JIRA.

[JIRA] (JENKINS-57304) Multiple "idle" entries on Build Executor Status for non-existant executors

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev updated  JENKINS-57304  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Released in 2.208  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-57304  
 
 
  Multiple "idle" entries on Build Executor Status for non-existant executors   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 
 
Status: 
 Fixed but Unreleased Resolved  
 
 
Released As: 
 (towards) Jenkins  2.208  
 

  
 
 
 
 

 
 
 

 
 
 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 discussi

[JIRA] (JENKINS-55811) Jenkins pipeline idle lightweight executor list is growing

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev updated  JENKINS-55811  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Most likely it was fixed in 2.208 by JENKINS-57304. Please test this new version and reopen the issue if it is not fully fixed  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-55811  
 
 
  Jenkins pipeline idle lightweight executor list is growing   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 
 
Status: 
 Open Fixed but Unreleased  
 
 
Resolution: 
 Duplicate  
 
 
Released As: 
 Jenkins 2.208  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60364) Environment variables not being set when Gerrit 2.14

Title: Message Title


 
 
 
 

 
 
 

 
   
 Felipe Santos updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60364  
 
 
  Environment variables not being set when Gerrit 2.14   
 

  
 
 
 
 

 
Change By: 
 Felipe Santos  
 
 
Attachment: 
 chrome_fjTOLApGQw.png  
 

  
 
 
 
 

 
 
 

 
 
 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.203387.1575461562000.3191.1575927240475%40Atlassian.JIRA.

[JIRA] (JENKINS-55484) Jenkins master zombie executors

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev resolved as Duplicate  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Most likely it was fixed in JENKINS-57304. Please test 2.208+ and report whether the issue still exists in your case  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-55484  
 
 
  Jenkins master zombie executors   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Duplicate  
 
 
Released As: 
 Jenkins 2.208  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60364) Environment variables not being set when Gerrit 2.14

Title: Message Title


 
 
 
 

 
 
 

 
   
 Felipe Santos commented on  JENKINS-60364  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Environment variables not being set when Gerrit 2.14   
 

  
 
 
 
 

 
 The upgrade to Gerrit 3.0 in our company is scheduled on the road-map for Q4 2020 (and I would love to change this, sadly I can't). The log isn't very clear. Did I configured it right?    
 

  
 
 
 
 

 
 
 

 
 
 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.203387.1575461562000.3193.1575927240655%40Atlassian.JIRA.

[JIRA] (JENKINS-60278) Empty field in Whitelisted Commands will cause an Oops and prevent saving

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev resolved as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 The fix was released in 2.208  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-60278  
 
 
  Empty field in Whitelisted Commands will cause an Oops and prevent saving   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Fixed  
 
 
Released As: 
 Jenkins 2.208  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  
 

  
 

   





-- 
You received this message because you are sub

[JIRA] (JENKINS-60364) Environment variables not being set when Gerrit 2.14

Title: Message Title


 
 
 
 

 
 
 

 
   
 Felipe Santos updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60364  
 
 
  Environment variables not being set when Gerrit 2.14   
 

  
 
 
 
 

 
Change By: 
 Felipe Santos  
 
 
Attachment: 
 gerrit-code-review-plugin.log  
 

  
 
 
 
 

 
 
 

 
 
 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.203387.1575461562000.3203.1575928140705%40Atlassian.JIRA.

[JIRA] (JENKINS-60348) Followup - Investigate root cause of idle executors

2019-12-09 Thread ian.willia...@telus.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Williams commented on  JENKINS-60348  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Followup - Investigate root cause of idle executors   
 

  
 
 
 
 

 
 Oleg Nenashev seems to have resolved in 2.208 under JENKINS-57304  
 

  
 
 
 
 

 
 
 

 
 
 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.203365.157536687.3201.1575928140349%40Atlassian.JIRA.

[JIRA] (JENKINS-60364) Environment variables not being set when Gerrit 2.14

Title: Message Title


 
 
 
 

 
 
 

 
   
 Felipe Santos commented on  JENKINS-60364  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Environment variables not being set when Gerrit 2.14   
 

  
 
 
 
 

 
 By using that logger configuration, I see one error that just occurs when trying to build an open change. The error happens all the time after hitting the button "Build now", only stops when the build finishes. Does't happen when trying to build from a branch (not a open change). The error seems to be the same every time, however, the stack trace is different. Log is attached to do not pollute the chat: gerrit-code-review-plugin.log   Dec 09, 2019 9:44:10 PM SEVERE jenkins.plugins.gerrit.ProjectChanges get Unable to retrieve change 6566742 Dec 09, 2019 9:44:10 PM FINER jenkins.plugins.gerrit.ProjectChanges get THROW com.urswolfer.gerrit.client.rest.http.HttpStatusException: Request not successful. Message: Bad Request. Status-Code: 400. Content: "TRACKING_IDS" is not a valid value for "-o". at com.urswolfer.gerrit.client.rest.http.GerritRestClient.throwHttpStatusException(GerritRestClient.java:494)      
 

  
 
 
 
 

 
 
 

 
 
 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.203387.1575461562000.3205.1575928320115%40Atlassian.JIRA.

[JIRA] (JENKINS-60365) Environment variables not being set on post-submit

Title: Message Title


 
 
 
 

 
 
 

 
   
 Felipe Santos commented on  JENKINS-60365  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Environment variables not being set on post-submit   
 

  
 
 
 
 

 
 That's right.  My use case:  
 
We produce a docker image for our repo on every commit and push it. For pre-submit commits, we tag it with the commit hash and the Gerrit change number. For post-submit we also does, alongside we also tag as :latest. In the end of the pipeline, we post comments on the change (gerritReview step) with a snippet for the docker pull command of that image matching the revision of the patchset.  
 This comment is useful to be posted also for post-submit commits, due to the fact that the commit author can have the image name of that desired commit without having to search (not every time the last patch-set (after hitting Submit) is the same of the latest one after pushing, because it gets rebased). However, there is another possibility the lack of these variables is depriving me: I want to tag my docker images with the Gerrit change number even after it gets merged, and for this I need the variable GERRIT_CHANGE_NUMBER and/or GERRIT_PATCHSET_NUMBER to be set. I'm pointing because switching from Gerrit Trigger lacks me this possibility and so far I have not found any no workaround.  
 

  
 
 
 
 

 
 
 

 
 
 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 em

[JIRA] (JENKINS-60365) Environment variables not being set on post-submit

Title: Message Title


 
 
 
 

 
 
 

 
   
 Felipe Santos edited a comment on  JENKINS-60365  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Environment variables not being set on post-submit   
 

  
 
 
 
 

 
 That's right. My use case: - We produce a docker image for our repo on every commit and push it. For pre-submit commits, we tag it with the commit hash and the Gerrit change number. For post-submit we also does, alongside we also tag as :latest. In the end of the pipeline, we post comments on the change (gerritReview step) with a snippet for the docker pull command of that image matching the revision of the patchset. This comment is useful to be posted also for post-submit commits, due to the fact that the commit author can have the image name of that desired commit without having to search (not every time the last patch-set (after hitting Submit) is the same of the latest one after pushing, because it gets rebased).However, there is another possibility the lack of these variables is depriving me:I want to tag my docker images with the Gerrit change number even after it gets merged, and for this I need the variable GERRIT_CHANGE_NUMBER and/or GERRIT_PATCHSET_NUMBER to be set. I'm pointing because switching from Gerrit Trigger lacks me this possibility and so So  far I have not found any no workaround.  
 

  
 
 
 
 

 
 
 

 
 
 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.203388.1575461

[JIRA] (JENKINS-60228) AdoptOpenJDK Plugin missed Java 13 support

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mads Mohr Christensen updated  JENKINS-60228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60228  
 
 
  AdoptOpenJDK Plugin missed Java 13 support   
 

  
 
 
 
 

 
Change By: 
 Mads Mohr Christensen  
 
 
Status: 
 Open Fixed but Unreleased  
 
 
Resolution: 
 Fixed  
 

  
 
 
 
 

 
 
 

 
 
 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.203203.1574254744000.3215.1575931080602%40Atlassian.JIRA.

[JIRA] (JENKINS-60228) AdoptOpenJDK Plugin missed Java 13 support

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mads Mohr Christensen updated  JENKINS-60228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60228  
 
 
  AdoptOpenJDK Plugin missed Java 13 support   
 

  
 
 
 
 

 
Change By: 
 Mads Mohr Christensen  
 
 
Status: 
 Fixed but Unreleased Closed  
 

  
 
 
 
 

 
 
 

 
 
 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.203203.1574254744000.3217.1575931080643%40Atlassian.JIRA.

[JIRA] (JENKINS-60228) AdoptOpenJDK Plugin missed Java 13 support

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mads Mohr Christensen stopped work on  JENKINS-60228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Mads Mohr Christensen  
 
 
Status: 
 In Progress Open  
 

  
 
 
 
 

 
 
 

 
 
 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.203203.1574254744000.3213.1575931080567%40Atlassian.JIRA.

[JIRA] (JENKINS-60228) AdoptOpenJDK Plugin missed Java 13 support