date:20191218

Title: Message Title


 
 
 
 

 
 
 

 
   
 Josh Soref edited a comment on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Ok, for us, there were apparently two items. I've switched things over to the other one. Hopefully that will make the alert go away.But this experience was painful.One thing that would help immensely is the ability to search for credentials whose password matches an entered value. Expected results should only include passwords the searching user is allowed to use. Had I been able to do that, I could have quickly identified the problem. Fwiw, the best I've managed is:{code:java}admin:org, admin:public_key, admin:repo_hook, read:user, repo {code}We had credentials of:{code:java}repo {code}{code:java}admin:repo_hook, repo {code}But they weren't sufficient for us.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Josh Soref commented on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Ok, for us, there were apparently two items. I've switched things over to the other one. Hopefully that will make the alert go away. But this experience was painful. One thing that would help immensely is the ability to search for credentials whose password matches an entered value. Expected results should only include passwords the searching user is allowed to use. Had I been able to do that, I could have quickly identified 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.203567.1576268869000.13358.1576715160212%40Atlassian.JIRA.

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite commented on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Maybe you're using the actual password from another location or through a different credential? I've not received any warnings from GitHub for my https repository access. I'll continue watching my mailbox in case it arrives.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Repository read should be enough [~jsoref], unless your job is pushing changes back to the server. I think we should document the credential choices as part of a larger picture of ways to use Jenkins most effectively with git.  When using GitHub, prefer username and a personal access tokens rather than username and password.  Same advice would apply to Bitbucket, Gitlab, Gitea, Team Foundation Server, and more.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Josh Soref commented on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Also, a quick look at my jenkins /credentials/store/system/domain/_/ shows that the account currently has a token with repo which was Last used within the last week according to github, and yet, I'm still getting warnings.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Repository read should be enough [~jsoref], unless your job is pushing changes back to the server.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite commented on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Repository read should be enough Josh Soref, unless your job is pushing changes back to the server.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Josh Soref commented on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Mark Waite: Do you know what permissions we should give it in https://github.com/settings/tokens/new? My ticket isn't claiming that work necessarily needs to be done in the plugin, just that a "what to do" should be published. (Although, probably it's best for the plugin to just guide people through the process since it seems like it'd be pretty easy for it to do that and remember "this token is good" or something.)  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60349) User credentials not usable by Git plugin

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite assigned an issue to Unassigned  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60349  
 
 
  User credentials not usable by Git plugin   
 

  
 
 
 
 

 
Change By: 
 Mark Waite  
 
 
Assignee: 
 Mark Waite  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60349) User credentials not usable by Git plugin

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite commented on  JENKINS-60349  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: User credentials not usable by Git plugin   
 

  
 
 
 
 

 
 Robert Schulze I can't do anything further on this without your answers to my questions.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite commented on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Isn't that message saying that you can continue to use basic auth so long as instead of using your actual password you use a personal access token. Generate a personal access token from the GitHub "Settings" page and store that personal access token in the Jenkins username / password credential as the password. Place your username as the username. Check that it works. It has been working that way for me.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60529) SSH authentication fails during submodule checkout from declarative pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite commented on  JENKINS-60529  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: SSH authentication fails during submodule checkout from declarative pipeline   
 

  
 
 
 
 

 
 Here is the declarative Pipeline that I defined to test submodule cloning from a private repository. The private repository is referenced in 3 different multibranch jobs in my test environment. One of those test environments uses ssh protocol. The other two use https protocol. The declarative pipeline job skips all stages when it detects that the URL protocol is not ssh. 

 
@Library('globalPipelineLibraryMarkEWaite') _

pipeline {
  agent {
label '!windows && git-1.8+' // Older git versions don't do submodules well, use an sh step later, no windows
  }
  options {
skipDefaultCheckout()
  }
  stages {
stage('checkout') {
  when {
// Only test when cloning from ssh protocol URL
// Submodule is defined with ssh protocol URL
_expression_ { scm.userRemoteConfigs[0].url ="" /g...@github.com:.*/ }
  }
  steps {
deleteDir()
checkout([$class: 'GitSCM',
  branches: scm.branches,
  userRemoteConfigs: scm.userRemoteConfigs,
  extensions: [
[$class: 'SubmoduleOption', parentCredentials: true],
[$class: 'LocalBranch', localBranch: 'JENKINS-60529'],
],
  gitTool: 'Default' // JGit in git client plugin does not fully support submodules
])
  }
}
stage('build') {
  when {
// Only test when cloning from ssh protocol URL
// Submodule is defined with ssh protocol URL
_expression_ { scm.userRemoteConfigs[0].url ="" /g...@github.com:.*/ }
  }
  steps {
echo 'SCM url is ' + scm.userRemoteConfigs[0].url
withAnt(installation: 'ant-latest', jdk: 'jdk8') {
  sh 'ant info'
}
  }
}
stage('verify') {
  when {
// Only test when cloning from ssh protocol URL
// Submodule is defined with ssh protocol URL
_expression_ { scm.userRemoteConfigs[0].url ="" /g...@github.com:.*/ }
  }
  steps {
logContains([expectedRegEx: ".*Found:.*JENKINS-57936.*",
   failureMessage: "Missing submodule README contents."])
  }
}
  }
}
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60534) Git Status Notification Fails With Folders

2019-12-18 Thread timothyo...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tim Orme created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60534  
 
 
  Git Status Notification Fails With Folders   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Kirill Merkushev  
 
 
Components: 
 github-plugin  
 
 
Created: 
 2019-12-18 23:04  
 
 
Environment: 
 Jenkins 2.190.3  Github 1.29.5  Folders 6.10.1  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Tim Orme  
 

  
 
 
 
 

 
 When using the GitHubCommitStatusSetter  class in a pipeline like so:   

 

void setBuildStatus(String repo, String message, String state) {
 step([
 $class: "GitHubCommitStatusSetter",
 reposSource: [$class: "ManuallyEnteredRepositorySource", url: repo],
 contextSource: [$class: "ManuallyEnteredCommitContextSource", context: "ci/jenkins/build-status"],
 errorHandlers: [[$class: "ChangingBuildStatusErrorHandler", result: "UNSTABLE"]],
 statusResultSource: [ $class: "ConditionalStatusResultSource", results: [[$class: "AnyBuildResult", message: message, state: state]] ]
 ]);
} 

 The plugin will report: ERROR: [GitHub Commit Status Setter] - Cannot retrieve Git metadata for the build, setting build result to UNSTABLE When used in conjunction with the Folders plugin, and the parent folder has a different name than the git repo has. So for instance, a folder structure like this correctly sets the status:   

 

my-project

--- build (checks out my-project)

--- release (checks out my-project)

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

2019-12-18 Thread car...@jenkins.co.cr (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Carlos Jenkins commented on  JENKINS-60480  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: github is deprecating basic authentication using password   
 

  
 
 
 
 

 
 Hi, I got the same email for two of my Jenkins deployments. That's how I got here  In particular the GitHub Branch Source Plugin only supports using username and password, so the functionality provided by that plugin may break when the deprecation takes place. Current code of the GitHub Branch Source Plugin shows: https://github.com/jenkinsci/github-branch-source-plugin/blob/23c8a226eef074da7b87bc4b629f6a9f75bf4766/src/main/java/org/jenkinsci/plugins/github_branch_source/Connector.java#L339    Looking at what PyGitHub does (project that I use with tokens to automate some things): https://github.com/PyGithub/PyGithub/blob/baddb7193f24fc988def1ead53876024be6066e0/github/Requester.py#L278      It looks like GitHub supports passing token in the Authorization header. So, in theory, the GitHub Branch Source Plugin could use a "Secret Text" type secret with the token an pass it down in the Authorization header. Its interesting to note that the GitHub Plugin already supports (actually only supports) using access tokens. So, in my Jenkins deployment I have to have two secrets: 
 
A "Username with password" type for GitHub Branch Source Plugin, and 
A "Secret text" for the GitHub plugin. 
      
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  
 

  
 

   





-- 
You received this message

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

2019-12-18 Thread car...@jenkins.co.cr (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Carlos Jenkins updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60480  
 
 
  github is deprecating basic authentication using password   
 

  
 
 
 
 

 
Change By: 
 Carlos Jenkins  
 
 
Attachment: 
 image-2019-12-18-16-29-44-602.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.203567.1576268869000.13299.1576708200301%40Atlassian.JIRA.

[JIRA] (JENKINS-60480) github is deprecating basic authentication using password

2019-12-18 Thread car...@jenkins.co.cr (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Carlos Jenkins updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60480  
 
 
  github is deprecating basic authentication using password   
 

  
 
 
 
 

 
Change By: 
 Carlos Jenkins  
 
 
Attachment: 
 image-2019-12-18-16-27-49-854.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.203567.1576268869000.13296.1576708080338%40Atlassian.JIRA.

[JIRA] (JENKINS-60533) support java 13 in versioncolumn-plugin

2019-12-18 Thread clem...@guillaume.bzh (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Clement Guillaume created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60533  
 
 
  support java 13 in versioncolumn-plugin   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Baptiste Mathus  
 
 
Components: 
 versioncolumn-plugin  
 
 
Created: 
 2019-12-18 22:01  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Clement Guillaume  
 

  
 
 
 
 

 
 

 

2019-12-18 20:00:53.974+ [id=22817] WARNING h.p.v.JVMVersionComparator#isAgentRuntimeCompatibleWithJenkinsBytecodeLevel: The agent JVM version 13.0 is not recognized by the plugin. You might want to open a ticket for the maintainer to complete the compatibility list.
2019-12-18 20:00:53.975+ [id=22817] WARNING h.p.v.JVMVersionComparator#isAgentRuntimeCompatibleWithJenkinsBytecodeLevel: The agent JVM version 13.0 is not recognized by the plugin. You might want to open a ticket for the maintainer to complete the compatibility list.
 

 possible fix here https://github.com/guillaumecle/versioncolumn-plugin  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60529) SSH authentication fails during submodule checkout from declarative pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite resolved as Not A Defect  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60529  
 
 
  SSH authentication fails during submodule checkout from declarative pipeline   
 

  
 
 
 
 

 
Change By: 
 Mark Waite  
 
 
Status: 
 Open Resolved  
 
 
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 jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203630.1576684421000.13254.1576704240676%40Atlassian.JIRA.

[JIRA] (JENKINS-45607) Potentialy spoofed IQ-packet from ejabberd 17.06 rejected by Smack filter

Title: Message Title


 
 
 
 

 
 
 

 
   
 Florian Schmaus closed an issue as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-45607  
 
 
  Potentialy spoofed IQ-packet from ejabberd 17.06 rejected by Smack filter   
 

  
 
 
 
 

 
Change By: 
 Florian Schmaus  
 
 
Status: 
 Resolved 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.183795.1500382028000.13223.1576701480271%40Atlassian.JIRA.

[JIRA] (JENKINS-45599) Upgrade Smack library to 4.1.9

Title: Message Title


 
 
 
 

 
 
 

 
   
 Florian Schmaus closed an issue as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-45599  
 
 
  Upgrade Smack library to 4.1.9   
 

  
 
 
 
 

 
Change By: 
 Florian Schmaus  
 
 
Status: 
 Resolved 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.183786.150036859.13224.1576701480283%40Atlassian.JIRA.

[JIRA] (JENKINS-51487) Update Smack to 4.3

Title: Message Title


 
 
 
 

 
 
 

 
   
 Florian Schmaus closed an issue as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-51487  
 
 
  Update Smack to 4.3   
 

  
 
 
 
 

 
Change By: 
 Florian Schmaus  
 
 
Status: 
 Resolved 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.190847.1527005759000.13220.1576701420618%40Atlassian.JIRA.

[JIRA] (JENKINS-60193) NPE in JabberPublisherDescriptor in new install

Title: Message Title


 
 
 
 

 
 
 

 
   
 Florian Schmaus updated  JENKINS-60193  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60193  
 
 
  NPE in JabberPublisherDescriptor in new install   
 

  
 
 
 
 

 
Change By: 
 Florian Schmaus  
 
 
Status: 
 In Review Resolved  
 
 
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.203163.1574067471000.13219.1576701420607%40Atlassian.JIRA.

[JIRA] (JENKINS-60193) NPE in JabberPublisherDescriptor in new install

Title: Message Title


 
 
 
 

 
 
 

 
   
 Florian Schmaus updated  JENKINS-60193  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60193  
 
 
  NPE in JabberPublisherDescriptor in new install   
 

  
 
 
 
 

 
Change By: 
 Florian Schmaus  
 
 
Resolution: 
 Fixed  
 
 
Status: 
 Resolved In Review  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60193) NPE in JabberPublisherDescriptor in new install

Title: Message Title


 
 
 
 

 
 
 

 
   
 Florian Schmaus updated  JENKINS-60193  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60193  
 
 
  NPE in JabberPublisherDescriptor in new install   
 

  
 
 
 
 

 
Change By: 
 Florian Schmaus  
 
 
Status: 
 In Review Resolved  
 
 
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.203163.1574067471000.13215.1576701300636%40Atlassian.JIRA.

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

2019-12-18 Thread o.v.nenas...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev commented on  JENKINS-60409  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cloud Configuration Length Cap   
 

  
 
 
 
 

 
 Daniel Beck  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-58211) ArtifactDeployer fails with java.lang.NoClassDefFoundError: Could not initialize class org.jruby.ext.posix.Linux64HeapFileStat

2019-12-18 Thread jmihal...@ubermedia.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Joe Mihalich commented on  JENKINS-58211  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ArtifactDeployer fails with java.lang.NoClassDefFoundError: Could not initialize class org.jruby.ext.posix.Linux64HeapFileStat   
 

  
 
 
 
 

 
 any idea when that's going to happen?  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60532) Build fails, but all stages and steps show successful when using nunit plugin and the test file doesn't exist

2019-12-18 Thread mbrun...@eidosmontreal.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Matthew Brunton created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60532  
 
 
  Build fails, but all stages and steps show successful when using nunit plugin and the test file doesn't exist   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 error-buildstage.PNG, error-stages.PNG, nunit-buildstage.PNG, nunit-stages.PNG  
 
 
Components: 
 nunit-plugin  
 
 
Created: 
 2019-12-18 17:47  
 
 
Environment: 
 Docker image jenkins/jenkins:2.208 in a docker network with a Perforce instance (https://github.com/p4paul/helix-docker) using p4-plugin 1.10.7, nunit-plugin 0.25, and blue-ocean 1.21  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Matthew Brunton  
 

  
 
 
 
 

 
 When using the nunit-plugin, if the test result file is not found, the plugin reports  

 
FATAL: No NUnit test report files were found. Configuration error? 

 The stage is marked as failure, however the build continues with the next stage as if it were a success. At the end, the build is marked as failure. In Blue Ocean, all steps/stages are marked as success, but the build at the end is marked as a failure.   I believe the expected result is that the error from nunit should act like any other error within a step and subsequent stages are skipped.   Output with nunit-plugin with no existing file

[JIRA] (JENKINS-60531) Make it possible for other plugins to analyze the full AST of a Declarative Pipeline

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

Title: Message Title


 
 
 
 

 
 
 

 
   
 Devin Nusbaum created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60531  
 
 
  Make it possible for other plugins to analyze the full AST of a Declarative Pipeline   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Devin Nusbaum  
 
 
Components: 
 pipeline-model-definition-plugin  
 
 
Created: 
 2019-12-18 17:36  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Devin Nusbaum  
 

  
 
 
 
 

 
 Right now, if a plugin wants to statically analyze the AST of a Declarative Pipeline, they can use ExecutionModelAction to get the AST underneath the top-level stages section of the Pipeline, and then use ModelValidator to walk that AST node and its children. There are two problems with this approach: 
 
ExecutionModelAction only stores the top-level stages, so there is no way to analyze the top-level agent, environment, options, etc. 
ModelValidator cannot be safely consumed from other plugins if backwards-incompatible changes are going to be made in the future (as they were when matrix was added to Declarative). 
 I think that extending ExecutionModelAction to store the full ModelASTPipelineDef instead of just ModelASTStages is uncontroversial, as long as the change is backwards compatible. I'm not sure about the best way to fix ModelValidator. Since the class is public, and in pipeline-model-api, my assumption was that it was intended to be a stable API. We could add an abstract implementation of that interface, and have the abstract implementation be a stable API, and add some Javadoc that indicates that the interface by itself is not stable. We could try to make the interface be stable from this point on, only adding new default methods, and never renaming or removing methods, but that might be a bit limiting. I submitted a PR that adds the full Pipeline to ExecutionModelAction and adds an abstract implementation of the

[JIRA] (JENKINS-60530) Adding gitlab MR comment from Jenkinsfile does not work

2019-12-18 Thread tadeuszkles...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Tadeusz Kleszcz created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60530  
 
 
  Adding gitlab MR comment from Jenkinsfile does not work   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Parichay Barpanda  
 
 
Components: 
 gitlab-branch-source-plugin, gitlab-plugin  
 
 
Created: 
 2019-12-18 17:23  
 
 
Environment: 
 Jenkins 2.190.1  GitLab Plugin 1.5.13  GitLab Branch Source Plugin 1.4.1  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 Tadeusz Kleszcz  
 

  
 
 
 
 

 
 Adding comment from Jenkinsfile during building Merge Request in Gitlab does not work. Jenkins job is created using Gitlab Branch Source plugin. The job type is Gitlab Group. When 

 
addGitLabMRComment 

 step is run gitlab MR comment is not added as expected and there is no error in build log. Sample Jenkinsfile to replicate this problem: 

 
pipeline {
  agent any
  stages {
stage('Build') {
  steps {
addGitLabMRComment comment: 'Test comment'
  }
}
  }
}

[JIRA] (JENKINS-59867) NodeJS tool installation fails on Windows Server 2019

2019-12-18 Thread r...@akom.net (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Alexander Komarov updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59867  
 
 
  NodeJS tool installation fails on Windows Server 2019   
 

  
 
 
 
 

 
Change By: 
 Alexander Komarov  
 
 
Summary: 
 NodeJS tool installation fails on Windows  Server 2019  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60513) Jenkins core 2.209: Warnings concerning AtomicInteger and class-filter

2019-12-18 Thread brandonsho...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Brandon Shough commented on  JENKINS-60513  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins core 2.209: Warnings concerning AtomicInteger and class-filter   
 

  
 
 
 
 

 
 Experiencing the same issue.  
 

  
 
 
 
 

 
 
 

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

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

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

Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Oost commented on  JENKINS-60405  
 

  
 
 
 
 

 
 
  
 
 
 
 

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

  
 
 
 
 

 
 Any news on this? Still no reply or update .. please, this is preventing me to deploy (automatically) for a week already...  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60527) Cloud Statistics Plugin(?) causing perpetually busy jenkins.util.Timer threads when cloud has problems

2019-12-18 Thread arn...@live.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Arnie Alpenbeach commented on  JENKINS-60527  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cloud Statistics Plugin(?) causing perpetually busy jenkins.util.Timer threads when cloud has problems   
 

  
 
 
 
 

 
 Additional information: Unlike the sleep() function made available by the Pipeline: Basic Steps plugin, java.lang.Thread.sleep() does not hang when the jenkins.util.Timer threads are jammed. The former looks to be implemented using jenkins.util.Timer: https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/SleepStep.java. I suspect that's why.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60351) can not disable the retries of Util.delete

2019-12-18 Thread jn...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 James Nord updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60351  
 
 
  can not disable the retries of Util.delete   
 

  
 
 
 
 

 
Change By: 
 James Nord  
 
 
Labels: 
 lts-candidate  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60529) SSH authentication fails during submodule checkout from declarative pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite commented on  JENKINS-60529  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: SSH authentication fails during submodule checkout from declarative pipeline   
 

  
 
 
 
 

 
 Usually a configuration error in the submodule definition. For example, if the parent repository is cloned with ssh, then the submodule repository must be defined to use an ssh protocol URL to the submodule repository. Command line git needs the same protocol in the submodule as in the parent repo because it needs to use the same credentials.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60529) SSH authentication fails during submodule checkout from declarative pipeline

2019-12-18 Thread rolando-mihai.v...@microfocus.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite assigned an issue to Unassigned  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60529  
 
 
  SSH authentication fails during submodule checkout from declarative pipeline   
 

  
 
 
 
 

 
Change By: 
 Mark Waite  
 
 
Assignee: 
 Mark Waite  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60529) SSH authentication fails during submodule checkout from declarative pipeline

2019-12-18 Thread simon.rich...@hogyros.de (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Simon Richter created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60529  
 
 
  SSH authentication fails during submodule checkout from declarative pipeline   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Mark Waite  
 
 
Components: 
 git-client-plugin, pipeline  
 
 
Created: 
 2019-12-18 15:53  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Simon Richter  
 

  
 
 
 
 

 
 Possibly similar to JENKINS-59546: I have a project with a Jenkinsfile containing a declarative pipeline in a git repository that also has submodules. I have activated submodule processing, and submodules are initialized correctly, but cloning them fails with a login error from the ssh connection opened by git. It seems that multiple keys are tried (I get two "Permission denied" messages), although credentials config inside the project explicitly specifies which key to use.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment

[JIRA] (JENKINS-60528) jenkins can't allocate mesos nodes duet to lock

2019-12-18 Thread hanbing2...@sina.cn (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 bing han created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60528  
 
 
  jenkins can't allocate mesos nodes duet to lock   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Vinod Kone  
 
 
Components: 
 mesos-plugin  
 
 
Created: 
 2019-12-18 15:42  
 
 
Environment: 
 mesos 0.17 jenkins 2.138.4 centos 7  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 bing han  
 

  
 
 
 
 

 
 There is a critical problem in mesos plugins 0.17. When a lot of job building in jenkins, jenkins master don't allocate mesos nodes and Mesos master produce a lot of outstanding offers.There is a critical problem in mesos plugins 0.17. When a lot of job building in jenkins, jenkins master don't allocate mesos nodes and Mesos master produce a lot of outstanding offers.We execute java command jstack -l 58(which is PID of jenkins master), as follow: "Thread-28255" #93222 prio=3 os_prio=0 tid=0x7f89c0975432 nid=0xe7 runnable (0x7f89c09432)           java.lang.Thread.state: RUNNABLE                at java.util.concurrent.LinkedBlockingQueue$LBQSpliterator.trySplit(LinkedBlockingQueue.java 890)                at java.util.stream.AbstractTask.compute(AbstractTask.java:297) at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731) at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) at java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:401) .. Lockeked owable synchronizers:         -<0x6089c0975> (a java.util.concurrent.locks.ReentranLock$NonfairSync)    -<0x6089c0968> (a java.util.concurrent.locks.ReentranLock$NonfairSync)    "mesos-offer-processor-6berferd-32re-45fd-12erdf6578uy-0026" #103 prio=5 os_prio=0 tid=0x7f89c0973451 nid=0xf7 waiting on condition[0x7f89c0971000]  java.lang.Thread.State: WAITING (parking)        at sun.misc.Unsafe.park(Native Method)    - parking to wait for <0x6089c0975> (a

[JIRA] (JENKINS-60527) Cloud Statistics Plugin(?) causing perpetually busy jenkins.util.Timer threads when cloud has problems

2019-12-18 Thread arn...@live.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Arnie Alpenbeach created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60527  
 
 
  Cloud Statistics Plugin(?) causing perpetually busy jenkins.util.Timer threads when cloud has problems   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Oliver Gondža  
 
 
Attachments: 
 java.util.Thread-dumps.log, org.jenkinsci.plugins.cloudstats.CloudStatistics.zip, serialized-program-state-during-sleep-hang.xml, zombie-jobs.png  
 
 
Components: 
 cloud-stats-plugin, openstack-cloud-plugin  
 
 
Created: 
 2019-12-18 15:39  
 
 
Environment: 
 Jenkins version: 2.190.3   Plugins:   ace-editor 1.1  ansicolor 0.6.2  ant 1.10  antisamy-markup-formatter 1.6  apache-httpcomponents-client-4-api 4.5.10-2.0  artifactory 3.4.1  authentication-tokens 1.3  authorize-project 1.3.0  bouncycastle-api 2.17  branch-api 2.5.5  build-failure-analyzer 1.24.0 false  build-flow-plugin 0.20  build-keeper-plugin 1.3  build-monitor-plugin 1.12+build.201809061734  build-name-setter 2.0.3  build-pipeline-plugin 1.5.8  build-timeout 1.19  build-timestamp 1.0.3  cloud-stats 0.25  cloudbees-disk-usage-simple 0.9  cloudbees-folder 6.10.0  command-launcher 1.4  conditional-buildstep 1.3.6  config-file-provider 3.6.2  credentials 2.3.0  credentials-binding 1.20  description-setter 1.10  display-url-api 2.3.2  docker-commons 1.15  docker-java-api 3.0.14  docker-plugin 1.1.9  docker-workflow 1.21  durable-task 1.33  envinject 2.3.0  envinject-api 1.7  external-monitor-job 1.7  ghprb 1.42.0  git 4.0.0  git-client 3.0.0  git-server 1.9  github 1.29.5  github-api 1.95  gradle 1.35  groovy 2.2  groovy-label-assignment 1.2.0  handlebars 1.1.1  icon-shim 2.0.3  ivy 2.1  jackson2-api 2.10.1  javadoc 1.5  jdk-tool 1.4  job-import-plugin 3.3  jobConfigHistory 2.24  jquery 1.12.4-1  jquery-detached 1.2.1  jquery-ui 1.0.2  jsch 0.1.55.1  junit 1.28  label-linked-jobs 5.1.2  ldap 1.21  lockable-resources 2.7  log-parser 2.1  mailer 1.29  mapdb-api 1.0.9.0  matrix-auth 2.5  matrix-project 1.14  maven-plugin 3.4  metrics 4.0.2.6  momentjs 1.1.1  multiple-scms 0.6  next-build-number 1.6  openstack-cloud 2.51-SNAPSHOT (private-658def72-peter)  pam-auth 1.6  Parameterized-Remote-Trigger 3.1.0  parameterized-trigger 2.36  pegdown-formatter 1.3  pipeline-build-step 2.10  pipeline-graph-analysis 1.10  pipeline-input-step 2.11  pipeline-milestone-step 1.3.1  pipeline-model-api 1.5.0  pipeline-model-declarative-agent 1.1.1  pipeline-model-definition 1.5.0  pipeline-model-extensions 1.5.0  pipeline-rest-api 2.12

[JIRA] (JENKINS-14750) Unprivileged view permissions for monitoring

2019-12-18 Thread belfas...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Belfast 77 commented on  JENKINS-14750  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Unprivileged view permissions for monitoring   
 

  
 
 
 
 

 
 +1  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60526) jenkins master allocating and removing mesos nodes slower

2019-12-18 Thread hanbing2...@sina.cn (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 bing han created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60526  
 
 
  jenkins master allocating and removing mesos nodes slower   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 core  
 
 
Created: 
 2019-12-18 15:35  
 
 
Environment: 
 centos 7 meos plugin 0.17 jenkins 2.138.4  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 bing han  
 

  
 
 
 
 

 
 There are a lot of building job in jenkins using mesos nodes (more than two hundrend), which happens allocating and removing mesos nodes slower than normal situaton.There are a lot of building job in jenkins using mesos nodes (more than two hundrend), which happens allocating and removing mesos nodes slower than normal situaton.We compile the Jenkins core code with some debug information log to jenkins.log As follow(core/src/main/java/jenkins/model/Nodes.java)   public void removeNode(final @Nonnull Node node) throws IOException {                   Logger.getLogger(Nodes.class.getName()).log(Level.INFO,"node.getNodeName boefore")        if (node == nodes.get(node.getNodeName())) {           Logger.getLogger(Nodes.class.getName()).log(Level.INFO,"removeNode Queue.withLock(new Runnable()  before")            Queue.withLock(new Runnable() {                   @Override                public void run() {      Logger.getLogger(Nodes.class.getName()).log(Level.INFO,"removeNode public void run()  enter")                                  Computer c = node.toComputer();                                  if (c != null)  {                                                 c.recordTermination();                                                         c.disconnect(OfflineCause.create(hudson.model.Messages._Hudson_NodeBeingRemoved()));                    }                                 if (node == nodes.remove(node.getNodeName()))  {

[JIRA] (JENKINS-60525) Plugin Synopsys Detect not showing in Configure System

2019-12-18 Thread igor.camilo...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Igor Camilovic created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60525  
 
 
  Plugin Synopsys Detect not showing in Configure System   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 James Richard  
 
 
Components: 
 synopsys-coverity-plugin  
 
 
Created: 
 2019-12-18 15:33  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Igor Camilovic  
 

  
 
 
 
 

 
 I have installed Synopsis Detect plugin via Plugin Manager. Next step is to configure plugin options in Manage Jenkins / Configure System, but there are no options for this plugin, and post-build action is missing also. In pipeline syntax option also there is nothing for this plugin. I have browsed all options on Jenkins and found nothing. This is the link to documentation of the plugin which clearly states to configure it in Configure System: https://synopsys.atlassian.net/wiki/spaces/INTDOCS/pages/71106939/Synopsys+Detect+for+Jenkins#SynopsysDetectforJenkins-Detectpipelinestep 
 
After installing, navigate to Manage Jenkins > Configure System. 
Navigate to the Synopsys Detect section, and complete the following.(trunc)

[JIRA] (JENKINS-49365) Resuming of pipelines vs. docker.image(...).inside(...)?

2019-12-18 Thread jgl...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jesse Glick commented on  JENKINS-49365  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Resuming of pipelines vs. docker.image(...).inside(...)?   
 

  
 
 
 
 

 
 No idea as to the root cause. Again the workaround would be simple: avoid the DSL and use withDockerContainer directly. (Or, better yet, avoid the whole plugin and run docker CLI commands from sh.)  
 

  
 
 
 
 

 
 
 

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

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

2019-12-18 Thread jwnmul...@java.net (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 jwnmulder commented on  JENKINS-60409  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cloud Configuration Length Cap   
 

  
 
 
 
 

 
 Running jenkins with -Dorg.eclipse.jetty.server.Request.maxFormContentSize=100" did resolve the issue for us  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-42957) Optimize Jenkinsfile loading instead of checking out all code on master

2019-12-18 Thread jgl...@cloudbees.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Jesse Glick resolved as Duplicate  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-42957  
 
 
  Optimize Jenkinsfile loading instead of checking out all code on master   
 

  
 
 
 
 

 
Change By: 
 Jesse Glick  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Duplicate  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-54010) Support two levels of parallelity in stages

2019-12-18 Thread shanid...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Shani Dar commented on  JENKINS-54010  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support two levels of parallelity in stages   
 

  
 
 
 
 

 
 Ian Katz I agree, I'm also waiting for this solution, that's what I did meanwhile until this issue will be 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.194623.1539245979000.12800.1576679882200%40Atlassian.JIRA.

[JIRA] (JENKINS-60514) Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rolando-Mihai Vlad commented on  JENKINS-60514  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"   
 

  
 
 
 
 

 
 Sure  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-54010) Support two levels of parallelity in stages

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-54010  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support two levels of parallelity in stages   
 

  
 
 
 
 

 
 That's a good workaround.  I can't speak for everyone here, but my personal interest in this issue is more to do with the first attached screenshot in the original issue -- the ability to have multiple sequential stages shown in each parallel branch.      In other words, to not have it all squish horizontally into a single stage that represents the entire branch.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-54010) Support two levels of parallelity in stages

2019-12-18 Thread rolando-mihai.v...@microfocus.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz commented on  JENKINS-54010  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support two levels of parallelity in stages   
 

  
 
 
 
 

 
 That's a good workaround. I can't speak for everyone here, but my personal interest in this issue is more to do with the first attached screenshot in the original issue – the ability to have multiple sequential stages shown in each parallel branch.   
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-58211) ArtifactDeployer fails with java.lang.NoClassDefFoundError: Could not initialize class org.jruby.ext.posix.Linux64HeapFileStat

2019-12-18 Thread m.win...@sap.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Markus Winter commented on  JENKINS-58211  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ArtifactDeployer fails with java.lang.NoClassDefFoundError: Could not initialize class org.jruby.ext.posix.Linux64HeapFileStat   
 

  
 
 
 
 

 
 There is already a pull request open that fixes the issue  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60514) Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"

2019-12-18 Thread yaniv...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Yaniv Katz commented on  JENKINS-60514  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"   
 

  
 
 
 
 

 
 GMT + 2  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60514) Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"

2019-12-18 Thread yaniv...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Yaniv Katz commented on  JENKINS-60514  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"   
 

  
 
 
 
 

 
 Hi Rolando,   Its not a case of running in the same slave machine. Each LR instance has a depreciated slave. We can make webex tomorrow at 11:00. Is it suitable for you?    Thanks, Yaniv  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60514) Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rolando-Mihai Vlad edited a comment on  JENKINS-60514  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"   
 

  
 
 
 
 

 
 Hello Yaniv Katz,I am unable to reproduce your issue and I would like to see the configurations. Is it possible to schedule a webex (my working hours are 9am-5pm GMT+2) until end of week, since I will be away due to holidays after?Please note, concurrent builds when using LoadRunner will cause issues since there can be only one instance of controller per machine. Regards,Rolando  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60514) Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"

2019-12-18 Thread rolando-mihai.v...@microfocus.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Rolando-Mihai Vlad commented on  JENKINS-60514  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"   
 

  
 
 
 
 

 
 Hello Yaniv Katz, I am unable to reproduce your issue and I would like to see the configurations. Is it possible to schedule a webex (my working hours are 9am-5pm GMT+2) until end of week, since I will be away due to holidays after? Please note, concurrent builds when using LoadRunner will cause issues since there can be only one instance of controller per machine.   Regards, Rolando  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is {{{"alg":"RS256"\}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. {{ 8675309 }}. # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}You should see all your

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is {{{"alg":"RS256"\}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. {{ 8675309 }} . # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}You should see all

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is {{{"alg":"RS256"\}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g.  \ {{ 8675309 }}. # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}You should see all

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is {{{"alg":"RS256"\}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. \{{ 8675309 }}. # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}You should see all

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is  \ {{ {"alg":"RS256"\}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. \{{ 8675309 }}. # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}. You should see

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is {{{"alg":"RS256"\}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. \{{ 8675309 }}. # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code} .  You should see all

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is \{{ {"alg":"RS256"}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. \{{ 8675309 }}. # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}. You should see all

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is \{{ {"alg":"RS256" \ }}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}} ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. \{{ 8675309 }}. # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}. # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}. You should see

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz edited a comment on  JENKINS-51225  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Support for GitHub Checks API   
 

  
 
 
 
 

 
 I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used: # set up a new GitHub app at [https://github.com/organizations/YOUR_ORG/settings/apps/new]. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app. # GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say {{/path/to/key.pem}}. You will also need your app ID from [https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name] # [Generate a JWT|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app], which consists of 3 base64-encoded chunks separated by {{.}} characters. For each of these chunks, delete all newlines and {{=}}, change all {{/}} to {{_}}, and change all {{+}} to {{-}}. ## The first chunk is \{{ {"alg":"RS256"}}} , base64-encoded. Literally {{eyJhbGciOiJSUzI1NiJ9}}   ## The second chunk is the base64-encoded result of a JSON object with 3 fields: {{iat}}, which holds the current unix epochal time (what you'd get from {{date -u '+%s'}}), {{exp}}, the expiration time (maximum of 600 more than {{iat}}, i.e. 10 minutes), and the issuer {{iss}} which should be set to your app ID ## The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:{code:java}echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64 {code}Note that {{openssl base64}} will split the signature over several lines, so just strip out the newlines   # With the JWT, we can [get the installation ID|https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation].{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/app/installations{code}This should return a JSON array with only one installation. Get its installation ID (the {{["id"]}} field), which will be an integer e.g. \{{ 8675309 }}.   # With the installation ID, we can get an installation token. This will have specific permissions for accesing the checks API on specific repositories (by default, all repositories – so we leave this blank).{code:java}curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" -d '{"permissions":{ "checks":"write"}}' https://api.github.com/app/installations/8675309/access_tokens{code}This will give you a response with a {{["token"]}} field, something like {{v1.fedcba9876543210}}.   # With the installation token, we can do a quick sanity check that we can "see" the repositories we want to access.{code:java}curl -s -H "Authorization: token v1.fedcba9876543210" -H "Accept: application/vnd.github.antiope-preview+json" -H "Accept: application/vnd.github.machine-man-preview+json" https://api.github.com/installation/repositories{code}. You should

[JIRA] (JENKINS-51225) Support for GitHub Checks API

Title: Message Title

Ian Katz commented on JENKINS-51225

Re: Support for GitHub Checks API

I got this working. First off, you can't use the GitHub Checks API with a user/password combo, nor with a token. You MUST set up a GitHub app to be able to generate the proper tokens. Here's the process I used:

set up a new GitHub app at https://github.com/organizations/YOUR_ORG/settings/apps/new. You can also do this from a user account, provided that the user account is listed as an owner of every repo for which you want to write status checks. (If you mess this up (like I did) you can use the "transfer app" option to move it to the right place.) The only required field should be the homepage URL, and you can put in a bogus one. Your app should be private, not public. Install that app.
GitHub will save a PRIVATE KEY to your computer; save it somewhere that your build machine can access it (we'll say /path/to/key.pem. You will also need your app ID from https://github.com/organizations/YOUR_ORG/settings/apps/your-app-name
Generate a JWT, which consists of 3 base64-encoded chunks separated by . characters. For each of these chunks, delete all newlines and =, change all / to _, and change all + to -.

The first chunk is {{ {"alg":"RS256"} }} , base64-encoded. Literally eyJhbGciOiJSUzI1NiJ9

The second chunk is the base64-encoded result of a JSON object with 3 fields: iat, which holds the current unix epochal time (what you'd get from date -u '+%s'), exp, the expiration time (maximum of 600 more than iat, i.e. 10 minutes), and the issuer iss which should be set to your app ID
The 3rd chunk is calculated with the shell as follows, as I'm not sure how to accomplish it in a pure-jenkins-groovy way:

echo "$CHUNK1.$CHUNK2" | openssl dgst -sha256 -sign /path/to/key.pem -binary | openssl base64

Note that openssl base64 will split the signature over several lines, so just strip out the newlines

With the JWT, we can get the installation ID.

curl -s -H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.YOUR_JWT_TOKEN.etc"

[JIRA] (JENKINS-51225) Support for GitHub Checks API

2019-12-18 Thread marianarcisa.ga...@microfocus.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Ian Katz updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-51225  
 
 
  Support for GitHub Checks API   
 

  
 
 
 
 

 
Change By: 
 Ian Katz  
 
 
Attachment: 
 Screen Shot 2019-12-18 at 8.19.18 AM.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.190545.1525878773000.12033.1576675442860%40Atlassian.JIRA.

[JIRA] (JENKINS-58211) ArtifactDeployer fails with java.lang.NoClassDefFoundError: Could not initialize class org.jruby.ext.posix.Linux64HeapFileStat

2019-12-18 Thread m...@shd.de (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Marco Menzel commented on  JENKINS-58211  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: ArtifactDeployer fails with java.lang.NoClassDefFoundError: Could not initialize class org.jruby.ext.posix.Linux64HeapFileStat   
 

  
 
 
 
 

 
 I've reproduced this bug on 2.190.3 and 2.209.  Every time I want to use the plugin [ArtifactDeployer] on a centOs build-slave. Is this something the developers of the plugin have to 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.200271.1561558166000.12031.1576673820564%40Atlassian.JIRA.

[JIRA] (JENKINS-57205) Null pointer exception in JGit pre-build merge

2019-12-18 Thread host...@post.cz (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Petr H commented on  JENKINS-57205  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Null pointer exception in JGit pre-build merge   
 

  
 
 
 
 

 
 I wouldn't rate this as a Minor bug. Today this started hitting us as well and it affected a lot of jobs at once. Could be rather caused by the git client plugin, but in the end the NPE occurs in the git plugin code.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-59341) patterns arg not being evaluated by the DSL plugin

2019-12-18 Thread ogon...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oliver Gondža closed an issue as Not A Defect  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 I am closing this as not a defect. Feel free to reopen in case there are some tools / docs that advise this syntax.  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-59341  
 
 
  patterns arg not being evaluated by the DSL plugin   
 

  
 
 
 
 

 
Change By: 
 Oliver Gondža  
 
 
Status: 
 In Progress 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-59341) patterns arg not being evaluated by the DSL plugin

2019-12-18 Thread ogon...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oliver Gondža edited a comment on  JENKINS-59341  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: patterns arg not being evaluated by the DSL plugin   
 

  
 
 
 
 

 
 Thanks for the report! Have this syntax ever worked? Where did you get that?The DSL  reference  generated on my instance suggests something like:  {noformat}patterns {pattern {pattern(String value)type(String value)}} {noformat}  -Which I have not made to work either.-  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-41805) Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.

2019-12-18 Thread ogon...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oliver Gondža commented on  JENKINS-41805  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.   
 

  
 
 
 
 

 
 Seeing the workarounds, I am wondering how wise it is to delete the pipeline helper folder(s) while the pipeline is still running.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60505) Microfocus Application Automation Tools Ver:6.0 not supporting ALM 12.55

Title: Message Title


 
 
 
 

 
 
 

 
   
 Maria Narcisa Galan assigned an issue to Roy Lu  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60505  
 
 
  Microfocus Application Automation Tools Ver:6.0 not supporting ALM 12.55   
 

  
 
 
 
 

 
Change By: 
 Maria Narcisa Galan  
 
 
Assignee: 
 Maria Narcisa Galan Roy Lu  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60514) Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"

2019-12-18 Thread marianarcisa.ga...@microfocus.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Maria Narcisa Galan assigned an issue to Rolando-Mihai Vlad  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60514  
 
 
  Message: "Publish Micro Focus tests result is waiting for a checkpoint on LR_AFF #42"   
 

  
 
 
 
 

 
Change By: 
 Maria Narcisa Galan  
 
 
Assignee: 
 Maria Narcisa Galan Rolando-Mihai Vlad  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-59789) Cleanup/GC Jenkins Slaves when Jenkins Master is removed

2019-12-18 Thread siegfried.kierma...@sap.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Sigi Kiermayer updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59789  
 
 
  Cleanup/GC Jenkins Slaves when Jenkins Master is removed   
 

  
 
 
 
 

 
Change By: 
 Sigi Kiermayer  
 
 
Issue Type: 
 Improvement Bug  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60419) Blocked classpaths are not shown on script approvals page

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aleksei Vesnin updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60419  
 
 
  Blocked classpaths are not shown on script approvals page   
 

  
 
 
 
 

 
Change By: 
 Aleksei Vesnin  
 

  
 
 
 
 

 
 Groovy classpaths for Extended Choice Parameter  in a workflow/pipeline job  for `Groovy Script`  are blocked with message `You have unapproved groovy scripts that need approval before they can be executed. Go to In-Process Script Approval page to approve your scripts.`, which is expected. But on the script approval page it says `No pending classpath entry approvals.`.For  freestyle jobs  `Groovy Script File`  it kind of works  with a groovy script file , I can approve or deny a classpath entries, but if multiple classpaths are defined and approved for a parameter, the parameter script doesn't see them. E. g. there are `src` and `resources` folders and class `src/io/domain/Config.groovy` which loads `resources/io/domain/config.yml`. When I only add `src` to the classpath it complains that it can't find `io/domain/config.yml` file, which is expected, but when both `src` and `resources` are added to the classpath (and both are approved), then the same script fails with `unable to resolve class io.domain.Config` exception, which is a bummer.  And with Groo These are probably two different classpath issues, please let me know if you need a separate ticket for the latter. Jenkins version: 2.190.3Extended Choice Parameter plugin version: 0.78   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60419) Blocked classpaths are not shown on script approvals page

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aleksei Vesnin updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60419  
 
 
  Blocked classpaths are not shown on script approvals page   
 

  
 
 
 
 

 
Change By: 
 Aleksei Vesnin  
 
 
Summary: 
 Blocked classpaths are not shown on script approvals page  (workflow job)  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60419) Blocked classpaths are not shown on script approvals page (workflow job)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aleksei Vesnin updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60419  
 
 
  Blocked classpaths are not shown on script approvals page (workflow job)   
 

  
 
 
 
 

 
Change By: 
 Aleksei Vesnin  
 

  
 
 
 
 

 
 Groovy classpaths for Extended Choice Parameter in a workflow/pipeline job are blocked with message `You have unapproved groovy scripts that need approval before they can be executed. Go to In-Process Script Approval page to approve your scripts.`, which is expected. But on the script approval page it says `No pending classpath entry approvals.`.For freestyle jobs it kind of works with a groovy script file, I can approve or deny a classpath entries, but if multiple classpaths are defined and approved for a parameter, the parameter script doesn't see them. E. g. there are `src` and `resources` folders and class `src/io/domain/Config.groovy` which loads `resources/io/domain/config.yml`. When I only add `src` to the classpath it complains that it can't find `io/domain/config.yml` file, which is expected, but when both `src` and `resources` are added to the classpath (and both are approved), then the same script fails with `unable to resolve class io.domain.Config` exception, which is a bummer. And  for   with Groo   These are probably two different classpath issues, please let me know if you need a separate ticket for the latter. Jenkins version: 2.190.3Extended Choice Parameter plugin version: 0.78   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script

2019-12-18 Thread brian.murr...@intel.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Brian J Murrell commented on  JENKINS-37984  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script   
 

  
 
 
 
 

 
 I will investigate if/how this helps the next time we hit the limit.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-56391) Whitespace entered during role assignments is handled inconsistently

2019-12-18 Thread o.v.nenas...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Oleg Nenashev resolved as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Fix was released in 2.16. https://github.com/jenkinsci/role-strategy-plugin/releases/tag/role-strategy-2.16  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-56391  
 
 
  Whitespace entered during role assignments is handled inconsistently   
 

  
 
 
 
 

 
Change By: 
 Oleg Nenashev  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Fixed  
 
 
Released As: 
 Role Strategy 2.16  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60419) Blocked classpaths are not shown on script approvals page (workflow job)

2019-12-18 Thread sergej.kl...@hermes-softlab.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Aleksei Vesnin updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60419  
 
 
  Blocked classpaths are not shown on script approvals page (workflow job)   
 

  
 
 
 
 

 
Change By: 
 Aleksei Vesnin  
 

  
 
 
 
 

 
 Groovy classpaths for Extended Choice Parameter in a workflow/pipeline job are blocked with message `You have unapproved groovy scripts that need approval before they can be executed. Go to In-Process Script Approval page to approve your scripts.`, which is expected. But on the script approval page it says `No pending classpath entry approvals.`.For freestyle jobs it kind of works  with a groovy script file , I can approve or deny a classpath entries, but if multiple classpaths are defined and approved for a parameter, the parameter script doesn't see them. E. g. there are `src` and `resources` folders and class `src/io/domain/Config.groovy` which loads `resources/io/domain/config.yml`. When I only add `src` to the classpath it complains that it can't find `io/domain/config.yml` file, which is expected, but when both `src` and `resources` are added to the classpath (and both are approved), then the same script fails with `unable to resolve class io.domain.Config` exception, which is a bummer.  And forThese are probably two different classpath issues, please let me know if you need a separate ticket for the latter. Jenkins version: 2.190.3Extended Choice Parameter plugin version: 0.78   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60477) Jenkins job is over running while creating jar files

2019-12-18 Thread divyaganesh1...@gmail.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Divya Ganesan commented on  JENKINS-60477  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins job is over running while creating jar files   
 

  
 
 
 
 

 
 Note: Also if configuration needed, Suggest only for job level, not globally.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-41149) Jenkins Promotion Using Wrong Workspace, Workspace@2

Title: Message Title


 
 
 
 

 
 
 

 
   
 Sergej Kleva commented on  JENKINS-41149  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins Promotion Using Wrong Workspace, Workspace@2   
 

  
 
 
 
 

 
 Interesting ... 2.27 also works only if run for the first time after install/reinstall. Afterwards, all new promotions are affected with the same bug   
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60524) Clarification on 'Improved CSRF protection for Jenkins 2.176.2'

2019-12-18 Thread nkane...@salesforce.com (JIRA)

Title: Message Title


 
 
 
 

 
 
 

 
   
 Neha Kanekar created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60524  
 
 
  Clarification on 'Improved CSRF protection for Jenkins 2.176.2'   
 

  
 
 
 
 

 
Issue Type: 
  Task  
 
 
Assignee: 
 Wadeck Follonier  
 
 
Components: 
 strict-crumb-issuer-plugin  
 
 
Created: 
 2019-12-18 10:17  
 
 
Environment: 
 Jenkins version : 2.190.3.2, Strict Crumb Issuer Plugin : 2.0.1  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Neha Kanekar  
 

  
 
 
 
 

 
 Regarding the Security advisory published here : https://jenkins.io/doc/upgrade-guide/2.176/#SECURITY-626, there's some improved CSRF protection (SECURITY-626). 1. Basically CSRF tokens (crumbs) are now only valid for the web session for which they were created. I want to understand here if there was any major issue with CSRF to introduce this change? 2. Also, to disable this improvement we can set the system property  hudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID to true.  Is this property setting a workaround to make CSRF protection backward compatible or is this going to be deprecated in future and crumb requests have to use cookies compulsorily?

[JIRA] (JENKINS-60141) Excessive number of "login -s" requests

Title: Message Title


 
 
 
 

 
 
 

 
   
 Charusheela Bopardikar edited a comment on  JENKINS-60141  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Excessive number of "login -s" requests   
 

  
 
 
 
 

 
 Refactored the code to reduce number of times login -s is called. [https://github.com/jenkinsci/p4-plugin/pull/112]  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-58949) If job fails in cleanup further triggering fails

Title: Message Title


 
 
 
 

 
 
 

 
   
 Charusheela Bopardikar assigned an issue to Charusheela Bopardikar  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58949  
 
 
  If job fails in cleanup further triggering fails   
 

  
 
 
 
 

 
Change By: 
 Charusheela Bopardikar  
 
 
Assignee: 
 Charusheela Bopardikar  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-56290) Impossible to Add Streams with Exact Names to Multibranch Pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Charusheela Bopardikar started work on  JENKINS-56290  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
Change By: 
 Charusheela Bopardikar  
 
 
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.197869.155119216.11786.1576662780788%40Atlassian.JIRA.

[JIRA] (JENKINS-56290) Impossible to Add Streams with Exact Names to Multibranch Pipeline

Title: Message Title


 
 
 
 

 
 
 

 
   
 Charusheela Bopardikar assigned an issue to Charusheela Bopardikar  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-56290  
 
 
  Impossible to Add Streams with Exact Names to Multibranch Pipeline   
 

  
 
 
 
 

 
Change By: 
 Charusheela Bopardikar  
 
 
Assignee: 
 Charusheela Bopardikar  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60516) Jenkins pipeline triggered for all branches on code commit in Develop branch

Title: Message Title


 
 
 
 

 
 
 

 
   
 Mark Waite edited a comment on  JENKINS-60516  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins pipeline triggered for all branches on code commit in Develop branch   
 

  
 
 
 
 

 
 You'll need to provide significantly more information so that others can duplicate the problem you're describing.  Refer to "[How to report an issue|https://wiki.jenkins.io/display/JENKINS/How+to+report+an+issue#Howtoreportanissue-WhatinformationtoprovideforEnvironmentandDescription]" for the guidelines.When maintainers choose which bug reports they will investigate, their choice is strongly influenced by the content and clarity of the bug report.If I spent several hours making guesses about the details of the configuration you are using, I could then describe what works and what doesn't work in my experiments.  However, it is very likely that my guesses will be different from your configuration in important ways.  Those differences could be the root of the problem.  It probably won't help you or me if I make guesses about the configuration you are using.Describe the issue in a way that someone like me can duplicate the problem based on your description of the problem.  Which plugins are you using?  What versions?  What is the detailed job configuration of the job that is showing the problem?  How are the webhooks configured on Bitbucket?  Which type of Bitbucket are you running, cloud or server?  Are there cases where the system behaves the way you want in this use case, or do you always have the poor behavior?   Are you using webhooks to notify Jenkins?   What arguments are included in the Bitbucket webhook call to Jenkins?  If you poll for changes, does it behave the same way, or does it only build on the branch that changed?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60516) Jenkins pipeline triggered for all branches on code commit in Develop branch

Title: Message Title

Mark Waite commented on JENKINS-60516

Re: Jenkins pipeline triggered for all branches on code commit in Develop branch

You'll need to provide significantly more information so that others can duplicate the problem you're describing. Refer to "How to report an issue" for the guidelines. When maintainers choose which bug reports they will investigate, their choice is strongly influenced by the content and clarity of the bug report. If I spent several hours making guesses about the details of the configuration you are using, I could then describe what works and what doesn't work in my experiments. However, it is very likely that my guesses will be different from your configuration in important ways. Those differences could be the root of the problem. It probably won't help you or me if I make guesses about the configuration you are using. Describe the issue in a way that someone like me can duplicate the problem based on your description of the problem. Which plugins are you using? What versions? What is the detailed job configuration of the job that is showing the problem? How are the webhooks configured on Bitbucket? Which type of Bitbucket are you running, cloud or server? Are there cases where the system behaves the way you want in this use case, or do you always have the poor behavior?

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

[JIRA] (JENKINS-60516) Jenkins pipeline triggered for all branches on code commit in Develop branch