[JIRA] (JENKINS-61687) Exceptions due to race condition during build deletion

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61687  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Exceptions due to race condition during build deletion   
 

  
 
 
 
 

 
 Would it be reasonable to specifically catch and swallow java.nio.file.NoSuchFileException from the Files.move call? Or would that just surface more concurrency problems in other parts of hudson.model.Run.delete?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61687) Exceptions due to race condition during build deletion

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61687  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Exceptions due to race condition during build deletion   
 

  
 
 
 
 

 
 

The problem occurs when many builds finish around the same time and is unrelated to the global build discarder.
 No, we got "An exception occurred when executing Project Build Discarder" from three consecutive builds even though there were several minutes of idle time between them. 
 

 
 
Build 
Start 
Get node 
Finish 
Build Discarder 
 
 
JobA #89 
08:38:24 
08:38:24 
08:44:29 
08:44:29 NoSuchFileException deleting JobA #39 
 
 
JobB #579 
08:49:18 
08:49:19 
08:53:32 
08:53:53 NoSuchFileException deleting JobB #529 
 
 
JobA #90 
10:18:40 
10:18:42 
10:24:18 
10:24:18 NoSuchFileException deleting JobA #40 
 
 
JobB #580 
10:19:50 
10:24:17 
10:28:53 
No error 
 
   

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 [BSERV-12284|https://jira.atlassian.com/browse/BSERV-12284] "Creating pull request does not reflect the stash-refs/pull-requests/<#> immediately" was moved to SHORT TERM BACKLOG on 2020-04-07. I wonder what Atlassian intends to do. It was then moved down to GATHERING INTEREST on 2020-04-14, and the priority was removed. :(  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 BSERV-12284 "Creating pull request does not reflect the stash-refs/pull-requests/<#> immediately" was moved to SHORT TERM BACKLOG on 2020-04-07. I wonder what Atlassian intends to do.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 I would recommend doing the "fromRef" thing instead of testing which REST requests update "refs/pull-requests/*/from" as an undocumented side effect.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 Does Bitbucket Server ensure that the "refs/pull-requests/{id}/from" ref appears (or is updated) immediately after the diff request, or can there be a delay sometimes?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 It looks like that is what the Bitbucket Branch Source plugin does anyway, for Bitbucket Cloud. So, fixing the "refs/pull-requests/{id}/from" problem for pull requests within the same repository in Bitbucket Server could be just a matter of removing a few instanceof BitbucketCloudApiClient checks in BitbucketGitSCMBuilder.java and BitbucketSCMFileSystem.java. Fixing it for pull requests between forks would need more changes.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 The newer Bitbucket Server Integration plugin does not even support pull requests yet, according to JENKINS-60342.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 I can think of two approaches that do not rely on Bitbucket Server updating the " / refs/pull-requests/\{id\}/from" ref: * Take the commit ID from the [webhook event payload|https://confluence.atlassian.com/bitbucketserver070/event-payload-996644369.html]. In [BSERV-8268|https://jira.atlassian.com/browse/BSERV-8268], Atlassian enabled {{uploadpack.allowReachableSHA1InWant}}, so this should work even if that commit is no longer the tip of any branch, as long as it is still reachable. However, if a user of Jenkins manually triggers a build, then I guess the webhook payload will not be available. * Query [/rest/api/1.0/projects/\{projectKey\}/repos/\{repositorySlug\}/pull-requests/\{pullRequestId\}|https://docs.atlassian.com/bitbucket-server/rest/7.0.1/bitbucket-rest.html#idp283] and get the name of the source branch from within the "fromRef" property.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 I can think of two approaches that do not rely on Bitbucket Server updating the "/refs/pull-requests/{id}/from" ref: 
 
Take the commit ID from the webhook event payload. In BSERV-8268, Atlassian enabled uploadpack.allowReachableSHA1InWant, so this should work even if that commit is no longer the tip of any branch, as long as it is still reachable. However, if a user of Jenkins manually triggers a build, then I guess the webhook payload will not be available. 
Query /rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/pull-requests/{pullRequestId} and get the name of the source branch from within the "fromRef" property. 
  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 The missing "/from" was filed two years ago as JENKINS-45997, and fixed in https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/116 by making the plugin poke the /rest/api/1.0/projects/{owner}/repos/{repo}/pull-requests/{id}/merge API, but that apparently stopped working in Bitbucket Server 7.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61493  
 
 
  Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 After upgrading to Bitbucket Server 7.0.1, we get this kind of error for every pull request in multibranch projects in which Jenkins has been configured to build the result of merging the pull request:{noformat} ERROR: Could not do lightweight checkout, falling back to heavyweight java.io.FileNotFoundException: URL: /rest/api/1.0/projects/REDACTED/repos/redacted/browse/Jenkinsfile?at=pull-requests%2F771%2Fmerge=0=500  at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getRequest(BitbucketServerAPIClient.java:831)  at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getFileContent(BitbucketServerAPIClient.java:1123)  at com.cloudbees.jenkins.plugins.bitbucket.filesystem.BitbucketSCMFile.content(BitbucketSCMFile.java:98)  at jenkins.scm.api.SCMFile.contentAsString(SCMFile.java:335)  at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)  at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)  at hudson.model.ResourceController.execute(ResourceController.java:97)  at hudson.model.Executor.run(Executor.java:427){noformat}{{git ls-remote origin}} shows that Bitbucket Server now publishes "refs/pull-requests/771/from" but not "refs/pull-requests/771/merge", even though the pull request has no merge conflicts (the target branch even has no new commits). This might be related to ["the switch from a 3-way diff to a 2-way diff in pull requests"|https://confluence.atlassian.com/bitbucketserver/bitbucket-server-7-0-release-notes-990546638.html#BitbucketServer7.0releasenotes-Amodifiedbehaviorfordiffs] in Bitbucket Server 7.0.0.Jenkins then does the heavyweight checkout and successfully merges the pull request, so the project ultimately builds OK, but the heavyweight checkout consumes a lot of time and disk space.There might not be any simple way to improve this in the bitbucket-branch-source plugin. If Bitbucket Server has deliberately ceased publishing "refs/pull-requests/*/merge", perhaps the plugin could do a three-way merge on Jenkinsfile only, rather than on the entire tree. - One way might be to use the REST API to get Jenkinsfile from the target branch ([/rest/api/1.0/projects/\{projectKey\}/repos/\{repositorySlug\}/browse/\{path:.*\}|https://docs.atlassian.com/bitbucket-server/rest/7.0.1/bitbucket-rest.html#idp208]) and any Jenkinsfile changes of the pull request as a patch  ( , and then apply the patch to Jenkinsfile at the Jenkins master. Unfortunately, it does not seem easy to get a patch that can be applied: ** [/rest/api/1.0/projects/\{projectKey\}/repos/\{repositorySlug\}/pull-requests/\{pullRequestId\}.patch|https://docs.atlassian.com/bitbucket-server/rest/7.0.1/bitbucket-rest.html#idp289] gives the standard diff format but does not support limiting to a single file ; . **  

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61493  
 
 
  Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Environment: 
 Jenkins 2.204.5Bitbucket Branch Source Plugin 2.7.0Bitbucket Server 7.0.1  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
 Mentioned in BSERV-11477 (comment).  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61493  
 
 
  Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 After upgrading to Bitbucket Server 7.0.1, we get this kind of error for every pull request in multibranch projects in which Jenkins has been configured to build the result of merging the pull request:{noformat} ERROR: Could not do lightweight checkout, falling back to heavyweight java.io.FileNotFoundException: URL: /rest/api/1.0/projects/REDACTED/repos/redacted/browse/Jenkinsfile?at=pull-requests%2F771%2Fmerge=0=500  at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getRequest(BitbucketServerAPIClient.java:831)  at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getFileContent(BitbucketServerAPIClient.java:1123)  at com.cloudbees.jenkins.plugins.bitbucket.filesystem.BitbucketSCMFile.content(BitbucketSCMFile.java:98)  at jenkins.scm.api.SCMFile.contentAsString(SCMFile.java:335)  at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)  at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)  at hudson.model.ResourceController.execute(ResourceController.java:97)  at hudson.model.Executor.run(Executor.java:427){noformat}{{git ls-remote origin}} shows that Bitbucket Server now publishes "refs/pull-requests/771/from" but not "refs/pull-requests/771/merge", even though the pull request has no merge conflicts (the target branch even has no new commits). This might be related to ["the switch from a 3-way diff to a 2-way diff in pull requests"|https://confluence.atlassian.com/bitbucketserver/bitbucket-server-7-0-release-notes-990546638.html#BitbucketServer7.0releasenotes-Amodifiedbehaviorfordiffs] in Bitbucket Server 7.0.0.Jenkins then does the heavyweight checkout and successfully merges the pull request, so the project ultimately builds OK, but the heavyweight checkout consumes a lot of time and disk space. I don't know whether there is There might not be  any simple way to  fix  improve  this in the bitbucket-branch-source plugin. If Bitbucket Server has deliberately ceased publishing "refs/pull-requests/*/merge", perhaps the plugin could do a three-way merge on Jenkinsfile only, rather than on the entire tree.  That would require  - One way might be to use the REST API to get Jenkinsfile from the target branch ([/rest/api/1.0/projects/\{projectKey\}/repos/\{repositorySlug\}/browse/\{path:.*\}|https://docs.atlassian.com/bitbucket-server/rest/7.0.1/bitbucket-rest.html#idp208]) and any Jenkinsfile changes of the pull request as  a  patch ([/rest/api/1.0/projects/\{projectKey\}/repos/\{repositorySlug\}/pull-requests/\{pullRequestId\}.patch|https://docs.atlassian.com/bitbucket-server/rest/7.0.1/bitbucket-rest.html#idp289] gives the standard diff format but does not support limiting to a single file; 

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61493  
 
 
  Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 After upgrading to Bitbucket Server 7.0.1, we get this kind of error for every pull request in multibranch projects in which Jenkins has been configured to build the result of merging the pull request:{noformat} ERROR: Could not do lightweight checkout, falling back to heavyweight java.io.FileNotFoundException: URL: /rest/api/1.0/projects/ SISU REDACTED /repos/ rahti-hybrid redacted /browse/Jenkinsfile?at=pull-requests%2F771%2Fmerge=0=500  at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getRequest(BitbucketServerAPIClient.java:831)  at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getFileContent(BitbucketServerAPIClient.java:1123)  at com.cloudbees.jenkins.plugins.bitbucket.filesystem.BitbucketSCMFile.content(BitbucketSCMFile.java:98)  at jenkins.scm.api.SCMFile.contentAsString(SCMFile.java:335)  at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)  at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)  at hudson.model.ResourceController.execute(ResourceController.java:97)  at hudson.model.Executor.run(Executor.java:427){noformat}{{git ls-remote origin}} shows that Bitbucket Server now publishes "refs/pull-requests/771/from" but not "refs/pull-requests/771/merge", even though the pull request has no merge conflicts (the target branch even has no new commits). This might be related to ["the switch from a 3-way diff to a 2-way diff in pull requests"|https://confluence.atlassian.com/bitbucketserver/bitbucket-server-7-0-release-notes-990546638.html#BitbucketServer7.0releasenotes-Amodifiedbehaviorfordiffs] in Bitbucket Server 7.0.0.Jenkins then does the heavyweight checkout and successfully merges the pull request, so the project ultimately builds OK, but the heavyweight checkout consumes a lot of time and disk space.I don't know whether there is any simple way to fix this in the bitbucket-branch-source plugin. If Bitbucket Server has deliberately ceased publishing "refs/pull-requests/*/merge", perhaps the plugin could do a three-way merge on Jenkinsfile only, rather than on the entire tree. That would require a REST API for getting the commit ID of a merge base though, and I don't know whether such a thing exists.  
 

  
 
 
 
 

 
 
 

 

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61493  
 
 
  Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/merge does not exist   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Summary: 
 Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/ from merge  does not exist  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61493) Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/from does not exist

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61493  
 
 
  Lightweight checkout fails in Bitbucket Server 7.0; refs/pull-requests/*/from does not exist   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 bitbucket-branch-source-plugin  
 
 
Created: 
 2020-03-16 12:03  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 After upgrading to Bitbucket Server 7.0.1, we get this kind of error for every pull request in multibranch projects in which Jenkins has been configured to build the result of merging the pull request: 

 
 ERROR: Could not do lightweight checkout, falling back to heavyweight
 java.io.FileNotFoundException: URL: /rest/api/1.0/projects/SISU/repos/rahti-hybrid/browse/Jenkinsfile?at=pull-requests%2F771%2Fmerge=0=500
 	at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getRequest(BitbucketServerAPIClient.java:831)
 	at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getFileContent(BitbucketServerAPIClient.java:1123)
 	at com.cloudbees.jenkins.plugins.bitbucket.filesystem.BitbucketSCMFile.content(BitbucketSCMFile.java:98)
 	at jenkins.scm.api.SCMFile.contentAsString(SCMFile.java:335)
 	at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:107)
 	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)
 	at hudson.model.ResourceController.execute(ResourceController.java:97)
 	at hudson.model.Executor.run(Executor.java:427)
 

 git ls-remote origin shows that Bitbucket Server now publishes "refs/pull-requests/771/from" but not "refs/pull-requests/771/merge", even though the pull request has no merge conflicts (the target branch even has no new commits). This 

[JIRA] (JENKINS-60340) BitBucket payload information is not injected in the Jenkins build

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60340  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: BitBucket payload information is not injected in the Jenkins build   
 

  
 
 
 
 

 
 I'd like the build scripts to see the actor parameter of the webhook event payload, i.e. who is the user whose actions triggered the build. This is not always the same as the author or committer that can be queried from Git.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-60960) Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream)

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60960  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Agent-side memory leak (ExportTable retaining some UNIXProcess$ProcessPipeInputStream)   
 

  
 
 
 
 

 
 The PR was merged and released in durable-task-1.34, but I don't know whether more changes are needed elsewhere.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61340) Cannot launch windows pods

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61340  
 
 
  Cannot launch windows pods   
 

  
 
 
 
 

 
 

Formatting didn't come out great
 I improved the formatting but can't help with the problem itself. The issue should perhaps be moved from INFRA to JENKINS though, if the problem occurs on your own Jenkins instance rather than on one maintained by the Jenkins project.  
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 Hi, Hi,   I'm trying to get windows pods working on GKE but for both the _jnlp_ and _shell_ container I get the following errors: ``` {quote} Error: failed to start container "jnlp": Error response from daemon: CreateComputeSystem jnlp: The system cannot find the file specified. ```  ``` {quote}{quote} Error: failed to start container "shell": Error response from daemon: CreateComputeSystem shell: The system cannot find the file specified. ```  {quote} This is using the sample pipeline: ``` {code:groovy} /*    * Runs a build on a Windows pod.    * Tested in EKS: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html    */  podTemplate(yaml: '''  apiVersion:  v1kind  v1kind :  Podspec  Podspec :     containers:     - name: jnlp       image: jenkins/jnlp-agent:latest-windows     - name: shell       image: mcr.microsoft.com/powershell:preview-windowsservercore-1809       command:       - powershell       args:       - Start-Sleep       - 99     nodeSelector:       beta.kubernetes.io/os: windows  ''')  \ {       node(POD_LABEL) {           container('shell') {               powershell 'Get-ChildItem Env: | Sort Name'           }       }  } ```  {code} Here's an outline the commands I used to setup the cluster: ``` {code:sh} gcloud beta container clusters create jenkins-cd \     --num-nodes 2 \     --machine-type n1-standard-2 \     --scopes "https://www.googleapis.com/auth/source.read_write,cloud-platform" \     --enable-ip-alias \     --release-channel=rapid  gcloud container clusters get-credentials jenkins-cd  gcloud beta container node-pools create windows-pool \     --cluster=jenkins-cd \     --image-type=WINDOWS_SAC \     --no-enable-autoupgrade \     --machine-type=n1-standard-2 ```  ``` {code}{code:sh} wget https://get.helm.sh/helm-v2.16.1-linux-amd64.tar.gz  tar zxfv helm-v2.16.1-linux-amd64.tar. gzcp gzcp  linux-amd64/helm .  kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account)  kubectl create 

[JIRA] (JENKINS-55574) interpolate variables in filters strings

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-55574  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: interpolate variables in filters strings   
 

  
 
 
 
 

 
 Can't you use Groovy's string interpolation instead? I believe this should work already: 

 

def arch = 'bar'
def myregex = ".*\\/foobar-${arch}\\/"
recordIssues filters: [excludeFile(myregex)], tools: [gcc4()]
 

 Here though, string interpolation would happen before the regular _expression_ is parsed. So if arch can contain regular _expression_ metacharacters but you want to match them as literal characters instead, then you might have to quote arch before inserting it to the regular _expression_: 

 

def myregex = ".*\\/foobar-${java.util.regex.Pattern.quote(arch)}\\/"
 

 I did not test any of this, though.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61331) Make the header "Jenkins" open the main menu, instead of the tiny arrow icon

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Make the header "Jenkins" open the main menu, instead of the tiny arrow icon   
 

  
 
 
 
 

 
 I moved this issue from the INFRA project to JENKINS because it does not seem to be "reporting a bug with the Jenkins web site, wiki, or any other services run by the Jenkins project" as described in How to report an issue. See also Infrastructure.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61329) Stack overflow error occurs while trying to delete some jobs

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61329  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Stack overflow error occurs while trying to delete some jobs   
 

  
 
 
 
 

 
 I moved this issue from the INFRA project to JENKINS because it does not seem to be "reporting a bug with the Jenkins web site, wiki, or any other services run by the Jenkins project" as described in How to report an issue. See also Infrastructure.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61330) mouseover popup disappears too fast

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61330  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: mouseover popup disappears too fast   
 

  
 
 
 
 

 
 I moved this issue from the INFRA project to JENKINS because it does not seem to be "reporting a bug with the Jenkins web site, wiki, or any other services run by the Jenkins project" as described in How to report an issue. See also Infrastructure.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61332) SSH agent in remote relative directory invokation, misuses relative path after chdir

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61332  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: SSH agent in remote relative directory invokation, misuses relative path after chdir   
 

  
 
 
 
 

 
 I moved this issue from the INFRA project to JENKINS because it does not seem to be "reporting a bug with the Jenkins web site, wiki, or any other services run by the Jenkins project" as described in How to report an issue. See also Infrastructure.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61328) JENKINS_URL being ignored. Defaulting to localhost

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-61328  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JENKINS_URL being ignored. Defaulting to localhost   
 

  
 
 
 
 

 
 I moved this issue from the INFRA project to JENKINS because it does not seem to be "reporting a bug with the Jenkins web site, wiki, or any other services run by the Jenkins project" as described in How to report an issue. See also Infrastructure.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61329) Stack overflow error occurs while trying to delete some jobs

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo moved an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61329  
 
 
  Stack overflow error occurs while trying to delete some jobs   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Project: 
 Infrastructure Jenkins  
 
 
Key: 
 INFRA JENKINS - 2455 61329  
 
 
Workflow: 
 classic default workflow JNJira + In-Review  
 
 
Component/s: 
 core  
 
 
Component/s: 
 core  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this 

[JIRA] (JENKINS-61331) Make the header "Jenkins" open the main menu, instead of the tiny arrow icon

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo moved an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61331  
 
 
  Make the header "Jenkins" open the main menu, instead of the tiny arrow icon   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Project: 
 Infrastructure Jenkins  
 
 
Key: 
 INFRA JENKINS - 2493 61331  
 
 
Workflow: 
 classic default workflow JNJira + In-Review  
 
 
Component/s: 
 core  
 
 
Component/s: 
 core  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 

[JIRA] (JENKINS-61330) mouseover popup disappears too fast

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo moved an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61330  
 
 
  mouseover popup disappears too fast   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Project: 
 Infrastructure Jenkins  
 
 
Key: 
 INFRA JENKINS - 2305 61330  
 
 
Workflow: 
 classic default workflow JNJira + In-Review  
 
 
Component/s: 
 core  
 
 
Component/s: 
 core  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are 

[JIRA] (JENKINS-61328) JENKINS_URL being ignored. Defaulting to localhost

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo moved an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61328  
 
 
  JENKINS_URL being ignored. Defaulting to localhost   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Project: 
 Infrastructure Jenkins  
 
 
Key: 
 INFRA JENKINS - 2498 61328  
 
 
Workflow: 
 classic default workflow JNJira + In-Review  
 
 
Component/s: 
 core  
 
 
Component/s: 
 core  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message 

[JIRA] (JENKINS-61332) SSH agent in remote relative directory invokation, misuses relative path after chdir

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo moved an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61332  
 
 
  SSH agent in remote relative directory invokation, misuses relative path after chdir   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Project: 
 Infrastructure Jenkins  
 
 
Key: 
 INFRA JENKINS - 2339 61332  
 
 
Workflow: 
 classic default workflow JNJira + In-Review  
 
 
Component/s: 
 core  
 
 
Component/s: 
 core  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   

[JIRA] (JENKINS-61277) Document that Bitbucket Server admin token credential secures itself by forcing to SYSTEM scope

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61277  
 
 
  Document that Bitbucket Server admin token credential secures itself by forcing to SYSTEM scope   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Labels: 
 security  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-61277) Document that Bitbucket Server admin token credential secures itself by forcing to SYSTEM scope

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61277  
 
 
  Document that Bitbucket Server admin token credential secures itself by forcing to SYSTEM scope   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Kristy Hughes  
 
 
Components: 
 atlassian-bitbucket-server-integration-plugin  
 
 
Created: 
 2020-02-29 08:33  
 
 
Environment: 
 Bitbucket Server Integration 1.1.0  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 The Bitbucket Server integration plugin expects an administrator to create a personal access token in Bitbucket Server and add it to Jenkins as a credential. The help text of this feature says: 
 
Providing this token will allow your users to automatically set up build triggers when creating Jenkins jobs. They won't be able to use it for anything else.
 At a first glance, this seems to fly against what is taught in Limitations of Credentials Masking and JENKINS-50242 (comment): that global credentials can be freely used by jobs. However, from looking at the credentials.xml file in the Jenkins master, the Bitbucket Server admin token actually has SYSTEM scope rather than GLOBAL scope, and there is no way to change the scope to GLOBAL in the user interface. I think the credential is actually secure as advertised, and the security does not depend on whether e.g. Credentials Binding Plugin can call methods of the com.atlassian.bitbucket.jenkins.internal.config.BitbucketTokenCredentialsImpl class via some interface. On the other hand, because the scope field does not appear in the UI for this type of credential, it is not obvious to a Jenkins administrator that the scope is SYSTEM, especially when other types of 

[JIRA] (JENKINS-61271) Disable build status notifications in Bitbucket Server Integration

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61271  
 
 
  Disable build status notifications in Bitbucket Server Integration   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Kristy Hughes  
 
 
Components: 
 atlassian-bitbucket-server-integration-plugin, skip-notifications-trait-plugin  
 
 
Created: 
 2020-02-28 09:44  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 Please add a way to configure the Atlassian-maintained Bitbucket Server Integration plugin not to report any build status to Bitbucket Server. This is similar to JENKINS-49216 / JENKINS-49471 / JENKINS-36755 for Bitbucket Branch Source There, the solution was to install Skip Notifications Trait Plugin and then add that trait to the branch sources. However, Bitbucket Server Integration does not seem to provide any withNotificationsDisabled method that Skip Notifications Trait could call. nor any other way to disable the notifications.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
  

[JIRA] (JENKINS-61271) Disable build status notifications in Bitbucket Server Integration

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61271  
 
 
  Disable build status notifications in Bitbucket Server Integration   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 Please add a way to configure the Atlassian-maintained Bitbucket Server Integration plugin not to report any build status to Bitbucket Server.This is similar to JENKINS-49216 / JENKINS-49471 / JENKINS-36755 for [Bitbucket Branch Source|https://plugins.jenkins.io/cloudbees-bitbucket-branch-source/] .  There, the solution was to install [Skip Notifications Trait Plugin|https://plugins.jenkins.io/skip-notifications-trait/] and then add that trait to the branch sources. However, Bitbucket Server Integration does not seem to provide any {{withNotificationsDisabled}} method that Skip Notifications Trait could call. nor any other way to disable the notifications.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To 

[JIRA] (JENKINS-60962) credential plugin security issue

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-60962  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: credential plugin security issue   
 

  
 
 
 
 

 
 This seems a duplicate of JENKINS-50242; as documented, Jenkins does not attempt to prevent malicious pipelines from revealing credentials to which they have  acess  access . See also JENKINS-42950 and [Limitations of Credentials Masking|https://jenkins.io/blog/2019/02/21/credentials-masking/] (aka WEBSITE-610).  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60962) credential plugin security issue

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60962  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: credential plugin security issue   
 

  
 
 
 
 

 
 This seems a duplicate of JENKINS-50242; as documented, Jenkins does not attempt to prevent malicious pipelines from revealing credentials to which they have acess. See also JENKINS-42950 and Limitations of Credentials Masking (aka WEBSITE-610).  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-58512) No page found '/io/jenkins/plugins/multibranch/BranchPriorityStrategy/config.jelly' for class jenkins.advancedqueue.PriorityConfiguration

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-58512  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: No page found '/io/jenkins/plugins/multibranch/BranchPriorityStrategy/config.jelly' for class jenkins.advancedqueue.PriorityConfiguration   
 

  
 
 
 
 

 
 The same happens with Jenkins 2.204.1  and 2.204.2  (LTS).  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-44450) Block scoped usage

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-44450  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Block scoped usage   
 

  
 
 
 
 

 
 Ulli Hafner, as the wiki is now read-only, do you accept comments on the requirements via some other channel?  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-43556) Stage View shows incorrect build result

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-43556  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Stage View shows incorrect build result   
 

  
 
 
 
 

 
 I was able to remove the incorrect data from the cache by calling com.cloudbees.workflow.flownode.FlowNodeUtil.CacheExtension.all().get(0).getRunCache().invalidate("the externalizable ID of the run") from the script console. Before that, I had tried "Reload Configuration from Disk" under "Manage Jenkins", but it had not cleared the cache, even though its description appears to say otherwise: "Discard all the loaded data in memory and reload everything from file system. Useful when you modified config files directly on disk."  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60342) Include support to BitBucket Pull Request

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60342  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Include support to BitBucket Pull Request   
 

  
 
 
 
 

 
 The older Bitbucket Branch Source plugin already supports the pr:opened, pr:merged, pr:declined, pr:deleted, and pr:reviewer:approved events from Bitbucket Server webhooks (HookEventType.java, NativeServerPullRequestHookProcessor.java), so this is necessary for feature parity.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo resolved as Fixed  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Fixed in configuration-as-code-plugin 1.35 with .  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-60045  
 
 
  JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Status: 
 Open Resolved  
 
 
Resolution: 
 Fixed  
 
 
Released As: 
 https://github.com/jenkinsci/configuration-as-code-plugin/releases/tag/configuration-as-code-1.35  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  
  

[JIRA] (JENKINS-58512) No page found '/io/jenkins/plugins/multibranch/BranchPriorityStrategy/config.jelly' for class jenkins.advancedqueue.PriorityConfiguration

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-58512  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: No page found '/io/jenkins/plugins/multibranch/BranchPriorityStrategy/config.jelly' for class jenkins.advancedqueue.PriorityConfiguration   
 

  
 
 
 
 

 
 The same happens with Jenkins 2.204.1 (LTS).  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-53492) Set priorities for Multibranch Pipelines

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-53492  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Set priorities for Multibranch Pipelines   
 

  
 
 
 
 

 
 There is now Multi-Branch priority sorter, which extends Priority Sorter but currently suffers from JENKINS-58512.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 Thanks, I see the git-client 3.1.0-beta binary is available from the [experimental update center|https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/].It seems to be working OK so far, when a multibranch pipeline with Bitbucket Branch Source  was merging  merges  a pull request to a branch in which LFS files have been modified. I also verified that attempting the same merges with git-client 3.0.0 causes the build to hang because of repetitive authentication errors.  (To verify this, I had to delete the workspace first, as Git LFS would otherwise have reused the LFS files that it cached when git-client 3.1.0-beta provided the credential.) I have not tested running {{checkout}} as a pipeline step from within Jenkinsfile, with either version of git-client.I should perhaps file a separate issue about the GIT_ASKPASS=echo environment variable.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 Thanks, I see the git-client 3.1.0-beta binary is available from the [experimental update center|https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/].It seems to be working OK so far, when  a multibranch pipeline with Bitbucket Branch Source was  merging a pull request to a branch in which LFS files have been modified. I also verified that attempting the same merges with git-client 3.0.0 causes the build to hang because of repetitive authentication errors.I  have not tested running {{checkout}} as a pipeline step from within Jenkinsfile, with either version of git-client.I  should perhaps file a separate issue about the GIT_ASKPASS=echo environment variable.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 Thanks, I see the git-client 3.1.0-beta binary is available from the [experimental update center|https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/].It seems to be working OK so far,  when merging a pull request to a branch  in  merges that involve some  which  LFS files , but I  have  not yet  been modified. I also  verified  whether  that attempting  the  previous version of the  same merges with  git-client  plugin would fail in these specific merges  3 . 0.0 causes the build to hang because of repetitive authentication errors.  I should perhaps file a separate issue about the GIT_ASKPASS=echo environment variable.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 Thanks, I see the git-client 3.1.0-beta binary is available from the [experimental update center|https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/]. It seems to be working OK so far, in merges that involve some LFS files, but I have not yet verified whether the previous version of the git-client plugin would fail in these specific merges.
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 Thanks, I see the git-client 3.1.0-beta binary is available from the experimental update center.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60045  
 
 
  JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Labels: 
 jcasc-compatibility  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-54154) [Custom Tools Plugin] - JCasC compatibility

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-54154  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: [Custom Tools Plugin] - JCasC compatibility   
 

  
 
 
 
 

 
 
 

 
tool:
  customTool:
installations: |-
  FAILED TO EXPORT
  com.cloudbees.jenkins.plugins.customtools.CustomTool$DescriptorImpl#installations: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.describe(DataBoundConfigurator.java:300) 


 This error has been filed as JENKINS-60045. Perhaps JENKINS-54154 can be resolved again.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this 

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-60045  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
 The exception was thrown during the {{newInstance}} call at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.describe([DataBoundConfigurator.java:299|https://github.com/jenkinsci/configuration-as-code-plugin/blob/c0528a7b412fd83908f2ef2ce5c32d2bb499823d/plugin/src/main/java/io/jenkins/plugins/casc/impl/configurators/DataBoundConfigurator.java#L299]):{code:java}T ref = (T) constructor.newInstance(args);{code}The type being constructed should be {{CustomTool}}, and I think it is. If the type had been {{CustomTool[]}} or {{ToolInstallation[]}} or {{ToolInstallation}}, then {{DataBoundConfigurator.getDataBoundConstructor}} would have returned null, and {{DefaultConfiguratorRegistry.internalLookup}} would not have created an instance of {{DataBoundConfigurator}}.So, it seems to be a matter of incorrect arguments being generated for the [{{CustomTool}} constructor|https://github.com/jenkinsci/custom-tools-plugin/blob/28152af024c2e5a3e46b02a3b185869488d3a6e4/src/main/java/com/cloudbees/jenkins/plugins/customtools/CustomTool.java#L94-L104].Perhaps the error is triggered by the {{@CheckForNull LabelSpecifics[] labelSpecifics}} parameter of that constructor. If [{{CustomTool.getLabelSpecifics}}|https://github.com/jenkinsci/custom-tools-plugin/blob/28152af024c2e5a3e46b02a3b185869488d3a6e4/src/main/java/com/cloudbees/jenkins/plugins/customtools/CustomTool.java#L132-L134] returns an array, then the type of this array does not implement {{java.util.Collection}}, so {{DataBoundConfiguration.describe}} assigns {{args[i] = Collections.singletonList(converted)}}, which is not acceptable to the constructor.If this theory is correct, then the error could be fixed either by changing {{CustomTool}} to use a collection type instead of the array type, or by changing {{ DataBoundConfiguration DataBoundConfigurator }} to check for array types as well. I cannot currently test these changes myself.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-60045  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
 The exception was thrown during the {{newInstance}} call at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.describe([DataBoundConfigurator.java:299|https://github.com/jenkinsci/configuration-as-code-plugin/blob/c0528a7b412fd83908f2ef2ce5c32d2bb499823d/plugin/src/main/java/io/jenkins/plugins/casc/impl/configurators/DataBoundConfigurator.java#L299]):{code:java}T ref = (T) constructor.newInstance(args);{code}The type being constructed should be {{CustomTool}}, and I think it is. If the type had been {{CustomTool[]}} or {{ToolInstallation[]}} or {{ToolInstallation}}, then {{DataBoundConfigurator.getDataBoundConstructor}} would have returned null, and {{DefaultConfiguratorRegistry.internalLookup}} would not have created an instance of {{DataBoundConfigurator}}.So, it seems to be a matter of incorrect arguments being generated for the [{{CustomTool}} constructor|https://github.com/jenkinsci/custom-tools-plugin/blob/28152af024c2e5a3e46b02a3b185869488d3a6e4/src/main/java/com/cloudbees/jenkins/plugins/customtools/CustomTool.java#L94-L104].Perhaps the error is triggered by the {{@CheckForNull LabelSpecifics[] labelSpecifics}} parameter of that constructor. If [{{CustomTool.getLabelSpecifics}}|https://github.com/jenkinsci/custom-tools-plugin/blob/28152af024c2e5a3e46b02a3b185869488d3a6e4/src/main/java/com/cloudbees/jenkins/plugins/customtools/CustomTool.java#L132-L134] returns an  empty  array, then the type of this array does not implement {{java.util.Collection}}, so {{DataBoundConfiguration.describe}} assigns {{args[i] = Collections.singletonList(converted)}}, which is not acceptable to the constructor.If this theory is correct, then the error could be fixed either by changing {{CustomTool}} to use a collection type instead of the array type, or by changing {{DataBoundConfiguration}} to check for array types as well. I cannot currently test these changes myself.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60045  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
 The exception was thrown during the newInstance call at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.describe(DataBoundConfigurator.java:299): 

 

T ref = (T) constructor.newInstance(args);
 

 The type being constructed should be CustomTool, and I think it is. If the type had been CustomTool[] or ToolInstallation[] or ToolInstallation, then DataBoundConfigurator.getDataBoundConstructor would have returned null, and DefaultConfiguratorRegistry.internalLookup would not have created an instance of DataBoundConfigurator. So, it seems to be a matter of incorrect arguments being generated for the CustomTool constructor. Perhaps the error is triggered by the @CheckForNull LabelSpecifics[] labelSpecifics parameter of that constructor. If CustomTool.getLabelSpecifics returns an empty array, then the type of this array does not implement java.util.Collection, so DataBoundConfiguration.describe assigns args[i] = Collections.singletonList(converted), which is not acceptable to the constructor. If this theory is correct, then the error could be fixed either by changing CustomTool to use a collection type instead of the array type, or by changing DataBoundConfiguration to check for array types as well. I cannot currently test these changes myself.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  
   

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60045  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
 I wonder if the error is triggered by com.cloudbees.jenkins.plugins.customtools.CustomTool$DescriptorImpl overriding setInstallations with a concrete type but not getInstallations.  Might be related to this comment in io.jenkins.plugins.casc.BaseConfigurator#describe: 

 

// Resolve the methods and merging overrides to more concretized signatures
// because the methods can to have been overridden with concretized type
// TODO: Overloaded setters with different types can corrupt this logic
 

  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-60045  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
 The whole A longer  stack trace from Jenkins 2.190.3,  Configuration as Code  Custom Tools  Plugin 0.7, Configuration as Code Plugin 1.34, Configuration as Code Support not installed:  {noformat}FAILED TO EXPORTcom.cloudbees.jenkins.plugins.customtools.CustomTool$DescriptorImpl#installations: java.lang.IllegalArgumentException: argument type mismatch  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.describe(DataBoundConfigurator.java:299)  at io.jenkins.plugins.casc.Attribute._describe(Attribute.java:264)  at io.jenkins.plugins.casc.Attribute.describe(Attribute.java:239)  at io.jenkins.plugins.casc.Configurator.describe(Configurator.java:162)  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:106)  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.lambda$describe$3(GlobalConfigurationCategoryConfigurator.java:99)  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator$$Lambda$286..accept(Unknown Source)  at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)  at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)  at java.util.Iterator.forEachRemaining(Iterator.java:116)  at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)  at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:497)  at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:487)  at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)  at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)  at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:241)  at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:99)  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:30){noformat}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 
   

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60045  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
 The whole stack trace from Jenkins 2.190.3, Configuration as Code Plugin 0.7, Configuration as Code Plugin 1.34, Configuration as Code Support not installed: 

 
FAILED TO EXPORT
com.cloudbees.jenkins.plugins.customtools.CustomTool$DescriptorImpl#installations: java.lang.IllegalArgumentException: argument type mismatch
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
  at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.describe(DataBoundConfigurator.java:299)
  at io.jenkins.plugins.casc.Attribute._describe(Attribute.java:264)
  at io.jenkins.plugins.casc.Attribute.describe(Attribute.java:239)
  at io.jenkins.plugins.casc.Configurator.describe(Configurator.java:162)
  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:106)
  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.lambda$describe$3(GlobalConfigurationCategoryConfigurator.java:99)
  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator$$Lambda$286..accept(Unknown Source)
  at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
  at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
  at java.util.Iterator.forEachRemaining(Iterator.java:116)
  at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
  at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:497)
  at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:487)
  at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
  at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
  at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:241)
  at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:99)
  at io.jenkins.plugins.casc.impl.configurators.GlobalConfigurationCategoryConfigurator.describe(GlobalConfigurationCategoryConfigurator.java:30)
 

  
 

  
 
 
 
 

 
 
 

 
 

[JIRA] (JENKINS-60045) JCasC export doesn't work with Custom Tools installed and configured

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-60045  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: JCasC export doesn't work with Custom Tools installed and configured   
 

  
 
 
 
 

 
 FWIW, the syntax for configuring custom tools via JCasC appears to be like this: 

 

tool:
  customTool:
installations:
- name: "DocFx"
  home: ""
  properties:
  - installSource:
  installers:
  - zip:
  label: "windows"
  url: "https://github.com/dotnet/docfx/releases/download/v2.39.2/docfx.zip"
 

  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-20073) Add an action to allow moving credentials between credential domains

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-20073  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add an action to allow moving credentials between credential domains   
 

  
 
 
 
 

 
 

Is there any reason why this issue should not be closed?
 src/test/java/com/cloudbees/plugins/credentials/CredentialsStoreActionTest.java does not yet contain a test for moving a credential. I guess that is why this issue is still open.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  
 

  
 

   





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

[JIRA] (JENKINS-58967) Credentials not available after upgrade to LTS 2.176.2

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-58967  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Credentials not available after upgrade to LTS 2.176.2   
 

  
 
 
 
 

 
 This seems to be working: 
 
Add a "jenkins-build" user to the security realm. 
Configure Authorize Project to run all builds as the "jenkins-build" user, without allowing per-job configuration. 
Add -Dcom.cloudbees.plugins.credentials.UseItemPermission=true to the Java options of the Jenkins master. 
Configure Role-based Authorization Strategy like this: 
 
Define the global role "build" with only these global permissions: 
 
Overall/Read (might not be necessary) 
Credentials/UseItem (this requires the option that was set above) 
Agent/Build 
Job/Read 
  
Assign the global role "build" to the user "jenkins-build". 
  
Add a certificate credential to the global credential domain of a multibranch pipeline job. 
Reference the credential using withCredentials in the Jenkinsfiles of branches of that job. 
 If I then log in as the "jenkins-build" user, I do not see the credentials, because of the missing Credentials/View permission. However, the builds can use the credentials just fine.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 

[JIRA] (JENKINS-20073) Add an action to allow moving credentials between credential domains

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-20073  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add an action to allow moving credentials between credential domains   
 

  
 
 
 
 

 
 AFAICT, this is already works  in Credentials Plugin 2.3.0 (and presumably has worked since version 1.16) ; if you have multiple credential domains in the same credential store, then the UI lets you move a credential from one domain to another. Is there any reason why this issue should not be closed?However, it is not yet possible to move credentials from one project or folder to another. That feature request been filed separately as JENKINS-20075.   
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-59331) withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name   
 

  
 
 
 
 

 
 Credentials Binding Plugin has done this ever since the certificate binding feature was added in [commit 7d789a8c590fd87cb9dd61c89c894a5df26a0605|https://github.com/jenkinsci/credentials-binding-plugin/commit/7d789a8c590fd87cb9dd61c89c894a5df26a0605] and merged in [PR#39|https://github.com/jenkinsci/credentials-binding-plugin/pull/39]. The commit message even mentions the assumption that the credential description matches the keystore alias name, but I don't think I have seen it documented anywhere else. When I edit the description of a certificate credential, the help text "An optional description to help tell similar credentials apart" certainly gives no hint of any such requirement.CertificateMultiBinding already calls {{credentials.getKeyStore()}}, so perhaps it could just enumerate the returned KeyStore and get the alias name from there, without needing changes in the Credentials Plugin. If the {{aliasVariable}} parameter is specified but the KeyStore actually contains more than one key, then CertificateMultiBinding could log a warning about that , perhaps unless the description of the credential matches one of these aliases .If each certificate credential normally contains only one certificate and private key, then the keystore alias name is not really needed for selecting the correct certificate, and I think users are likely to choose short words like "cert" as keystore alias names. If the {{withCredentials}} step is then changed to store these to the {{aliasVariable}}, there may be a risk that Jenkins starts unnecessarily masking this word in unrelated output. Perhaps the keystore alias name should be exempt from this masking, like JENKINS-44860 requests for usernames.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
  

[JIRA] (JENKINS-60317) Encrypt the temporary keystore and keys with a random password in certificate binding

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60317  
 
 
  Encrypt the temporary keystore and keys with a random password in certificate binding   
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 credentials-binding-plugin  
 
 
Created: 
 2019-11-28 11:59  
 
 
Environment: 
 Jenkins 2.190.3  Credentials Binding Plugin 1.20  Credentials Plugin 2.3.0  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 Current behaviour Nowadays, when the Credentials Binding Plugin is used on a certificate credential, CertificateMultiBinding calls credentials.getPassword() and credentials.getKeyStore() and saves the KeyStore to a temporary file encrypted with this password. Typically, any private keys within the KeyStore have already been encrypted with the same password; otherwise, the Credentials Plugin would have warned about the unaccessible key when the PKCS#12 file was uploaded to Jenkins. Desired change CertificateMultiBinding could be changed to generate a random password and use that when it passes the credential to the job. This would mean: 
 
Generate a cryptographically random temporary password. 
Create a temporary KeyStore. 
Enumerate the KeyStore of the credential. Decrypt each key with the password of the credential, encrypt with the temporary password, and add to the temporary KeyStore. 
Save the temporary KeyStore to the temporary file, encrypting it with the temporary password. 
Pass the temporary password to the 

[JIRA] (JENKINS-59331) withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name   
 

  
 
 
 
 

 
 Credentials Binding Plugin has done this ever since the certificate binding feature was added in [commit 7d789a8c590fd87cb9dd61c89c894a5df26a0605|https://github.com/jenkinsci/credentials-binding-plugin/commit/7d789a8c590fd87cb9dd61c89c894a5df26a0605] and merged in [PR#39|https://github.com/jenkinsci/credentials-binding-plugin/pull/39]. The commit message even mentions the assumption that the credential description matches the keystore alias name, but I don't think I have seen it documented anywhere else. When I edit the description of a certificate credential, the help text "An optional description to help tell similar credentials apart" certainly gives no hint of any such requirement.CertificateMultiBinding already calls {{credentials.getKeyStore()}}, so perhaps it could just enumerate the returned KeyStore and get the alias name from there, without needing changes in the Credentials Plugin. If the {{aliasVariable}} parameter is specified but the KeyStore actually contains more than one key, then CertificateMultiBinding could log a warning about that.If each certificate credential normally contains only one certificate and private key, then the keystore alias name is not really needed for selecting the correct certificate, and I think users are likely to choose short words like "cert" as keystore alias names. If the {{withCredentials}} step is then changed to store these to the {{aliasVariable}}, there may be a risk that Jenkins starts unnecessarily masking this word in unrelated output. Perhaps the keystore alias name should be exempt from this masking , like JENKINS-44860 requests for usernames .  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 
   

[JIRA] (JENKINS-59331) withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name   
 

  
 
 
 
 

 
 In the Certificate Plugin, CertificateCredentialsImpl.KeyStoreSourceDescriptor#validateCertificateKeystore apparently supports multiple certificate entries and multiple key entries in the same KeyStore. StandardCertificateCredentials.NameProvider#getSubjectDN only uses one key entry, though.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-20073) Add an action to allow moving credentials between credential domains

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-20073  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add an action to allow moving credentials between credential domains   
 

  
 
 
 
 

 
 AFAICT, this is already works; if you have multiple credential domains in the same credential store, then the UI lets you move a credential from one domain to another. Is there any reason why this issue should not be closed? However, it is not yet possible to move credentials from one project or folder to another. That feature request been filed separately as JENKINS-20075.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-59331) withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name   
 

  
 
 
 
 

 
 Credentials Binding Plugin has done this ever since the certificate binding feature was added in [commit 7d789a8c590fd87cb9dd61c89c894a5df26a0605|https://github.com/jenkinsci/credentials-binding-plugin/commit/7d789a8c590fd87cb9dd61c89c894a5df26a0605] and merged in [PR#39|https://github.com/jenkinsci/credentials-binding-plugin/pull/39]. The commit message even mentions the assumption that the credential description matches the keystore alias name, but I don't think I have seen it documented anywhere else. When I edit the description of a certificate credential, the help text "An optional description to help tell similar credentials apart" certainly gives no hint of any such requirement.CertificateMultiBinding already calls {{credentials.getKeyStore()}}, so perhaps it could just enumerate the returned KeyStore and get the alias name from there, without needing changes in the Credentials Plugin. If the {{aliasVariable}} parameter is specified but the KeyStore actually contains more than one key, then CertificateMultiBinding could log a warning about that. If each certificate credential normally contains only one certificate and private key, then the keystore alias name is not really needed for selecting the correct certificate, and I think users are likely to choose short words like "cert" as keystore alias names. If the {{withCredentials}} step is then changed to store these to the {{aliasVariable}}, there may be a risk that Jenkins starts unnecessarily masking this word in unrelated output. Perhaps the keystore alias name should be exempt from this masking.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

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

 
   
 

  

[JIRA] (JENKINS-59331) withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name   
 

  
 
 
 
 

 
 Credentials Binding Plugin has done this ever since the certificate binding feature was added  in  [commit 7d789a8c590fd87cb9dd61c89c894a5df26a0605|https://github.com/jenkinsci/credentials-binding-plugin/commit/7d789a8c590fd87cb9dd61c89c894a5df26a0605] and merged in [PR#39|https://github.com/jenkinsci/credentials-binding-plugin/pull/39]. The commit message even mentions the assumption that the credential description matches the keystore alias name, but I don't think I have seen it documented anywhere else. When I edit the description of a certificate credential, the help text "An optional description to help tell similar credentials apart" certainly gives no hint of any such requirement.CertificateMultiBinding already calls {{credentials.getKeyStore()}}, so perhaps it could just enumerate the returned KeyStore and get the alias name from there, without needing changes in the Credentials Plugin. If the {{aliasVariable}} parameter is specified but the KeyStore actually contains more than one key, then CertificateMultiBinding could log a warning about that.  
 

  
 
 
 
 

 
 
 

 
 
 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 

[JIRA] (JENKINS-59331) withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name   
 

  
 
 
 
 

 
 Credentials Binding Plugin has done this ever since the certificate binding feature was added commit 7d789a8c590fd87cb9dd61c89c894a5df26a0605 and merged in PR#39. The commit message even mentions the assumption that the credential description matches the keystore alias name, but I don't think I have seen it documented anywhere else. When I edit the description of a certificate credential, the help text "An optional description to help tell similar credentials apart" certainly gives no hint of any such requirement. CertificateMultiBinding already calls credentials.getKeyStore(), so perhaps it could just enumerate the returned KeyStore and get the alias name from there, without needing changes in the Credentials Plugin. If the aliasVariable parameter is specified but the KeyStore actually contains more than one key, then CertificateMultiBinding could log a warning about that.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-59331) withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-59331  
 
 
  withCredentials certificate(aliasVariable: ) stores description of credential, not keystore alias name   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 
 
Summary: 
 Empty 'Alias Variable' when using withCredentials  certificate  binding (aliasVariable: ) stores description of credential, not keystore alias name  
 
 
Issue Type: 
 Task 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.201882.1568291887000.7856.1574879940251%40Atlassian.JIRA.

[JIRA] (JENKINS-59331) Empty 'Alias Variable' when using certificate binding

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Empty 'Alias Variable' when using certificate binding   
 

  
 
 
 
 

 
 I see a similar result with Jenkins ver. 2.190.3, Credentials Binding Plugin 1.20, and Credentials Plugin 2.3.0. I defined a step like this in a declarative pipeline Jenkinsfile:{code}withCredentials([certificate(credentialsId: 'APK-signing',keystoreVariable: 'AndroidSigningKeyStore',passwordVariable: 'AndroidSigningStorePass',aliasVariable: 'AndroidSigningKeyAlias')]) {writeFile encoding: 'UTF-8', file: 'AndroidSigningKeyAlias.txt', text: env.AndroidSigningKeyAlias// actual signing not shown}{code}and, what was written to AndroidSigningKeyAlias.txt was not the "keystore alias name" documented in [https://jenkins.io/doc/pipeline/steps/credentials-binding/], but instead the description of the credential. The keystore alias name was actually the same as in the PKCS#12 file from which I had imported the credential to Jenkins. [CertificateMultiBinding#bind|https://github.com/jenkinsci/credentials-binding-plugin/blob/dfb2c2d560dbb52a771d16e9490a6455d3174388/src/main/java/org/jenkinsci/plugins/credentialsbinding/impl/CertificateMultiBinding.java#L79-L80]:{code:java}  if(aliasVariable!=null && !aliasVariable.isEmpty())   m.put(aliasVariable, credentials.getDescription());{code} I guess the original reporter had not added a description to the credential, and the alias variable was thus left empty.  
 

  
 
 
 
 

 
 
 

 
 
 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 

[JIRA] (JENKINS-59331) Empty 'Alias Variable' when using certificate binding

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Empty 'Alias Variable' when using certificate binding   
 

  
 
 
 
 

 
 I see a similar result with Jenkins ver. 2.190.3  and ,  Credentials Binding Plugin 1.20 , and Credentials Plugin 2 . 3.0.   I defined a step like this in a declarative pipeline Jenkinsfile:  {code :groovy }withCredentials([certificate(credentialsId: 'APK-signing',keystoreVariable: 'AndroidSigningKeyStore',passwordVariable: 'AndroidSigningStorePass',aliasVariable: 'AndroidSigningKeyAlias')]) {writeFile encoding: 'UTF-8', file: 'AndroidSigningKeyAlias.txt', text: env.AndroidSigningKeyAlias// actual signing not shown}{code}  and, what was written to AndroidSigningKeyAlias.txt was not the "keystore alias name" documented in [https://jenkins.io/doc/pipeline/steps/credentials-binding/], but instead the description of the credential. The keystore alias name was actually the same as in the PKCS#12 file from which I had imported the credential to Jenkins.I guess the original reporter had not added a description to the credential, and the alias variable was thus left empty.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-59331) Empty 'Alias Variable' when using certificate binding

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-59331  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Empty 'Alias Variable' when using certificate binding   
 

  
 
 
 
 

 
 I see a similar result with Jenkins ver. 2.190.3 and Credentials Binding Plugin 1.20. I defined a step like this in a declarative pipeline Jenkinsfile: 

 

withCredentials([certificate(
credentialsId: 'APK-signing',
keystoreVariable: 'AndroidSigningKeyStore',
passwordVariable: 'AndroidSigningStorePass',
aliasVariable: 'AndroidSigningKeyAlias')]) {
writeFile encoding: 'UTF-8', file: 'AndroidSigningKeyAlias.txt', text: env.AndroidSigningKeyAlias
// actual signing not shown
}
 

 and, what was written to AndroidSigningKeyAlias.txt was not the "keystore alias name" documented in https://jenkins.io/doc/pipeline/steps/credentials-binding/, but instead the description of the credential. The keystore alias name was actually the same as in the PKCS#12 file from which I had imported the credential to Jenkins. I guess the original reporter had not added a description to the credential, and the alias variable was thus left empty.  
 

  
 
 
 
 

 
 
 

 
 
 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-54538) Ability to save unmasked credentials to file

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-54538  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Ability to save unmasked credentials to file   
 

  
 
 
 
 

 
 https://jenkins.io/doc/pipeline/steps/credentials-binding/ says this is by design: "The masking could of course be trivially circumvented; anyone permitted to configure a job or define Pipeline steps is assumed to be trusted to use any credentials in scope however they like."  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-60128) UserAgentInterceptor generates User-Agent header with spaces in product identifier

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60128  
 
 
  UserAgentInterceptor generates User-Agent header with spaces in product identifier   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Kristy Hughes  
 
 
Components: 
 atlassian-bitbucket-server-integration-plugin  
 
 
Created: 
 2019-11-11 11:02  
 
 
Priority: 
  Trivial  
 
 
Reporter: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 src/main/java/com/atlassian/bitbucket/jenkins/internal/http/HttpRequestExecutorImpl.java generates a string that is then placed in the User-Agent header field of HTTP requests: 

 

bbJenkinsUserAgent = "Bitbucket Jenkins Integration/" + version;
 

 According to the specification of the User-Agent header field in RFC 7231 and the definition of token in RFC 7230, a product identifier cannot contain space characters. As the string is apparently intended to contain only one product identifier rather than three, it should instead be something like "Bitbucket-Jenkins-Integration/" + version.  
 

  
 
 
 
 

 
 
 

 
 
 Add 

[JIRA] (JENKINS-60127) UserAgentInterceptor searches for old plugin name "atlassian-bitbucket-server-scm"

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60127  
 
 
  UserAgentInterceptor searches for old plugin name "atlassian-bitbucket-server-scm"   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Kristy Hughes  
 
 
Components: 
 atlassian-bitbucket-server-integration-plugin  
 
 
Created: 
 2019-11-11 10:55  
 
 
Priority: 
  Trivial  
 
 
Reporter: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 src/main/java/com/atlassian/bitbucket/jenkins/internal/http/HttpRequestExecutorImpl.java checks the version number of "atlassian-bitbucket-server-scm": 

 

Plugin plugin = Jenkins.get().getPlugin("atlassian-bitbucket-server-scm");
if (plugin != null) {
version = plugin.getWrapper().getVersion();
}
 

 In pom.xml however, the plugin is called "atlassian-bitbucket-server-integration": 

 

atlassian-bitbucket-server-integration
 

 The string "atlassian-bitbucket-server-scm" appears nowhere else in the source tree. It was removed from another file in commit 26f839ad2c1632c1ab150612a664439093b32107.  
 

  
 
 
 
 

 

[JIRA] (JENKINS-47717) Allow different "Discard Old Build" options per branch on multibranch pipelines

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-47717  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Allow different "Discard Old Build" options per branch on multibranch pipelines   
 

  
 
 
 
 

 
 roe_p pinhas, AFAIK, it works OK in a Multibranch Pipeline, where each branch becomes a nested project that discards its builds independently from the other branches.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-48897) Cannot add credentials for Bitbucket on branch sources section in Multibranch pipeline

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-48897  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot add credentials for Bitbucket on branch sources section in Multibranch pipeline   
 

  
 
 
 
 

 
 Youssef El Houti, if the REST APIs of Bitbucket Server support SSH authentication, https://docs.atlassian.com/bitbucket-server/rest/6.6.0/bitbucket-rest.html#authentication does not describe how to use it over HTTP. Also, https://confluence.atlassian.com/bitbucketserver/ssh-user-keys-for-personal-use-776639793.html talks about using SSH keys for Git operations and does not mention any way to use them for other operations. I can imagine a few ways for Atlassian to allow SSH authentication for REST APIs in some future version of Bitbucket Server: 
 
Provide a command that can be run over SSH to retrieve a temporary token for the REST APIs, similar to git-lfs-authenticate. 
Use the SSH keys in the experimental HTTP Origin-Bound Authentication (HOBA) scheme specified in RFC 7486. Atlassian could either implement that directly in Bitbucket Server or implement BSERV-3239 and let someone else implement HOBA for Tomcat or Apache. 
 I did not find any requests for such features at jira.atlassian.com, though.  
 

  
 
 
 
 

 
 
 

 
 
 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-41891) Serve static files from second domain as an alternative to setting CSP

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-41891  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Serve static files from second domain as an alternative to setting CSP   
 

  
 
 
 
 

 
 The frame-ancestors directive of Content-Security-Policy cannot distinguish between https://dev.mycorp.com/jenkins/ and https://dev.mycorp.com/static-jenkins/. See CSP: frame-ancestors should check origins, not URLs · Issue #311 · w3c/webappsec. The HTTP cookies set by Jenkins seem to be using HostOnly and HttpOnly, except the "screenResolution" cookie. I think this makes https://static.dev.mycorp.com/ and https://static-dev.mycorp.com/ less risky than they might otherwise be.  
 

  
 
 
 
 

 
 
 

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

[JIRA] (JENKINS-48897) Cannot add credentials for Bitbucket on branch sources section in Multibranch pipeline

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-48897  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cannot add credentials for Bitbucket on branch sources section in Multibranch pipeline   
 

  
 
 
 
 

 
 Because Bitbucket Server does not support SSH credentials for actions such as retrieving Jenkinsfile (without cloning the whole repository) and reporting the build status.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





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

[JIRA] (JENKINS-47748) Second archiveArtifacts step fails silently with compress-artifacts-plugin

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-47748  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Second archiveArtifacts step fails silently with compress-artifacts-plugin   
 

  
 
 
 
 

 
 Lubo Varga, a workaround might be to stash the files from each node and unstash all of them to the same node, then archive them from there using only one archiveArtifacts step.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.186239.150945526.25908.1560337681402%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-38257) Feature to define non-actual user

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-38257  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Feature to define non-actual user   
 

  
 
 
 
 

 
 Jenkins 2.176.1 LTS now includes JENKINS-24513, which warns about builds running as SYSTEM. But virtual users are difficult to define when Jenkins is using SAML Plugin against Microsoft's AD FS. I wonder if, instead of the "significant changes" in JENKINS-32596, this could be implemented: 
 
as a security realm wrapper plugin that lets the admin select an inner security realm for the real users and define some additional virtual users, 
or as a composite security realm plugin that lets the admin select two or more inner security realms, one of which could then be Jenkins’ own user database. 
  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.174420.1473972094000.25310.1560269040321%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-57477) Cancelling a job results in "sendctrlc.x64...exe" stops working

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-57477  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Cancelling a job results in "sendctrlc.x64...exe" stops working   
 

  
 
 
 
 

 
 We also run LTS here, but installing Microsoft Visual C++ 2013 Redistributable (x64) - 12.0.40649 solved the crashes easily. I suggest not hurrying with the backport, in case there is some unexpected problem with the new winp version.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.196067.1544012607000.7783.1558454220242%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-47891) Bitbucket branch source plugin does not understand the new Bitbucket Server webhooks

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-47891  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Bitbucket branch source plugin does not understand the new Bitbucket Server webhooks   
 

  
 
 
 
 

 
 Torsten Kleiber wrote: 

Native Webhooks does not work for Pull requests here:
 In your screenshot, the webhook URI ends with "/bitbucket-hook/". That path seems to be handled by Bitbucket plugin and Bitbucket Push and Pull Request plugin, which do not support Bitbucket Server native webhooks. Bitbucket Branch Source plugin instead uses a URI like "https://jenkins.example/bitbucket-scmsource-hook/notify?server_url=http://bitbucket.example:7990", where the server_url parameter must match what you have in "Bitbucket Endpoints" in the Jenkins configuration.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-55345) DocFX info messages count as warnings

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-55345  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: DocFX info messages count as warnings   
 

  
 
 
 
 

 
 

Interested in providing a PR?
 Not yet. I'd need to study Maven etc. first.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-55345) DocFX info messages count as warnings

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55345  
 
 
  DocFX info messages count as warnings   
 

  
 
 
 
 

 
Change By: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 DocFX wrote several entries like this to its log file:{code:json}{"message":"For git repo , using branch 'warnings-ng' from the environment variable Git_Branch.","source":"BuildCore.Build Document.Load.TocDocumentProcessor","file":"toc.yml","date_time":"2018-12-26T20:23:53.8113472Z","message_severity":"info","correlation_id":"4A74E517-AC4E-49E8-ADDF-0635EB7796D9.117.1.31.2.4"}{code}The Warnings Next Generation Plug-in treated this as a low-severity warning; it showed up in the number-of-warnings graph and in the list of warnings. However, this is not really a warning and should be excluded from those. Furthermore, the values of the "file" property varied between builds (perhaps due to race conditions and caching), so the plug-in often treated some of the warnings as new. About  Analysis Model API Plug-in 1.0.0 uses violations-lib 1.73 and analysis-model 1.1.0. In violations-lib, [DocFXParser|https://github.com/tomasbjerre/violations-lib/blob/1.73/src/main/java/se/bjurr/violations/lib/parsers/DocFXParser.java] translates "info" to {{SEVERITY.INFO}}. In analysis-model, [DocFxAdapter|https://github.com/jenkinsci/analysis-model/blob/analysis-model-1.1.0/src/main/java/edu/hm/hafner/analysis/parser/violations/DocFxAdapter.java] is derived from [AbstractViolationAdapter|https://github.com/jenkinsci/analysis-model/blob/analysis-model-1.1.0/src/main/java/edu/hm/hafner/analysis/parser/violations/AbstractViolationAdapter.java], which translates {{SEVERITY.INFO}} to {{Severity.WARNING_LOW}}.I think DocFxAdapter should override {{isValid}} and discard the violation if the severity is {{SEVERITY.INFO}}. ([DocFX additionally supports "verbose" and "diagnostic"|https://github.com/dotnet/docfx/blob/v2.39.2/src/Microsoft.DocAsCode.Common/Loggers/ReportLogListener.cs#L132], but DocFxParser translates those to {{SEVERITY.INFO}} as well.)I first tried to work around this problem by configuring a filter for warnings-ng, but it does not seem possible to filter on the message or severity. I was able to work around the problem by running DocFX with the {{--logLevel Warning}} option, so that the info messages didn't appear in the log file and the console log at all, but I would prefer not using that option because the info messages may be useful for troubleshooting.  
 

  
 
 
 
 

 
 
 

 
 

[JIRA] (JENKINS-55345) DocFX info messages count as warnings

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55345  
 
 
  DocFX info messages count as warnings   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Ulli Hafner  
 
 
Components: 
 analysis-model-api-plugin, warnings-ng-plugin  
 
 
Created: 
 2018-12-27 12:47  
 
 
Environment: 
 DocFX 2.39.2  Jenkins 2.150.1  warnings-ng 1.0.0  analysis-model-api 1.0.0  violations-lib 1.73  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Kalle Niemitalo  
 

  
 
 
 
 

 
 DocFX wrote several entries like this to its log file: 

 

{"message":"For git repo , using branch 'warnings-ng' from the environment variable Git_Branch.","source":"BuildCore.Build Document.Load.TocDocumentProcessor","file":"toc.yml","date_time":"2018-12-26T20:23:53.8113472Z","message_severity":"info","correlation_id":"4A74E517-AC4E-49E8-ADDF-0635EB7796D9.117.1.31.2.4"}
 

 The Warnings Next Generation Plug-in treated this as a low-severity warning; it showed up in the number-of-warnings graph and in the list of warnings. However, this is not really a warning and should be excluded from those. Furthermore, the values of the "file" property varied between builds (perhaps due to race conditions and caching), so the plug-in often treated some of the warnings as new. About Analysis Model API Plug-in 1.0.0 uses violations-lib 1.73 and analysis-model 1.1.0. In violations-lib, DocFXParser translates "info" to SEVERITY.INFO. In analysis-model, DocFxAdapter is derived from AbstractViolationAdapter, which translates SEVERITY.INFO to Severity.WARNING_LOW. I think DocFxAdapter should override isValid and 

[JIRA] (JENKINS-1735) Add SOAP query to get web pages for MSBuild warnings

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-1735  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add SOAP query to get web pages for MSBuild warnings   
 

  
 
 
 
 

 
 The SOAP service at http://services.msdn.microsoft.com/search/service.asmx finds a search result for "CS0168" but none for "CS4014", even though that is documented at https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/cs4014. I suspect the service is used by an old version of Visual Studio and has not been taught about warnings added by later versions.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-26948) Workflow compatibility for MsBuildBuilder

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-26948  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Workflow compatibility for MsBuildBuilder   
 

  
 
 
 
 

 
 {quote}For later versions of MSBuild that come with Visual Studio, I think the best way is to run vswhere (which could be a custom tool) and derive the path of MSBuild.exe from its output.{quote}I put this in one stage:{code}environment {VSWHERE_DIR = tool(type: 'com.cloudbees.jenkins.plugins.customtools.CustomTool', name: 'vswhere')}{code}Then this as the first step:{code}script {// The @ sign prevents CMD.EXE from echoing the command and// thus messing up the JSON output.def VisualStudioInstances = readJSON( text: bat( script: '@"%VSWHERE_DIR%\\vswhere.exe" -products Microsoft.VisualStudio.Product.BuildTools Microsoft.VisualStudio.Product.Professional -requires Microsoft.Component.MSBuild -format json', returnStdout: true))def VisualStudioInstallationPath = VisualStudioInstances[0].installationPathecho "Using Visual Studio from ${VisualStudioInstallationPath}"  env. MSBUILD_DIR VSDEVCMD_BAT  = VisualStudioInstallationPath + '\\ MSBuild Common7 \\ 15.0 Tools \\ Bin vsdevcmd.bat ' echo "Using }{code}And the step to run  MSBuild  from $ : { env.MSBUILD_DIR code:groovy } bat 'CALL " %VSDEVCMD_BAT%" && MSBuild.exe /property:Platform="Any CPU",Configuration="Release" /target:Restore;Build "SOLUTION.sln"'  {code } The projects in this solution use [PackageReference rather than packages.config|https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files], so Jenkinsfile can use { code {/target:Restore } } instead of locating and running {{nuget.exe}}.   This seems to work but a few things could be improved: - Error handling, if no matching version of Visual Studio has been installed. - Also recognize Enterprise, Express, and Community editions. Perhaps it's best to say {{-products *}}. -  Can we get the {{\MSBuild\15.0\Bin}} part from vswhere somehow? - Could use NuGet to install vswhere. Then, only NuGet itself would need to be configured as a custom tool. -  Perhaps move to a sharable pipeline library.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

[JIRA] (JENKINS-26948) Workflow compatibility for MsBuildBuilder

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-26948  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Workflow compatibility for MsBuildBuilder   
 

  
 
 
 
 

 
 

For later versions of MSBuild that come with Visual Studio, I think the best way is to run vswhere (which could be a custom tool) and derive the path of MSBuild.exe from its output.
 I put this in one stage: 

 

environment {
VSWHERE_DIR = tool(type: 'com.cloudbees.jenkins.plugins.customtools.CustomTool', name: 'vswhere')
}
 

 Then this as the first step: 

 

script {
// The @ sign prevents CMD.EXE from echoing the command and
// thus messing up the JSON output.
def VisualStudioInstances = readJSON(
text: bat(
script: '@"%VSWHERE_DIR%\\vswhere.exe" -products Microsoft.VisualStudio.Product.BuildTools Microsoft.VisualStudio.Product.Professional -requires Microsoft.Component.MSBuild -format json',
returnStdout: true))

def VisualStudioInstallationPath = VisualStudioInstances[0].installationPath
echo "Using Visual Studio from ${VisualStudioInstallationPath}"

env.MSBUILD_DIR = VisualStudioInstallationPath + '\\MSBuild\\15.0\\Bin'
echo "Using MSBuild from ${env.MSBUILD_DIR}"
}
 

 This seems to work but a few things could be improved: 
 
Error handling, if no matching version of Visual Studio has been installed. 
Also recognize Enterprise, Express, and Community editions. Perhaps it's best to say -products *. 
Can we get the \MSBuild\15.0\Bin part from vswhere somehow? 
Could use NuGet to install vswhere. Then, only NuGet itself would need to be configured as a custom tool. 
Perhaps move to a sharable pipeline library. 
  
 

  
 
 
 
 

 
 
 

 
  

[JIRA] (JENKINS-46250) Allow Bitbucket build status text to be overridden

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo edited a comment on  JENKINS-46250  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Allow Bitbucket build status text to be overridden   
 

  
 
 
 
 

 
 See also [ Skip Notifications Trait 1.0.0 \[BSERV-3857\] Add 'Unstable' Build Status |https:// plugins jira . jenkins atlassian . io com / skip browse/BSERV - notifications-trait 3857 ]  works OK here. I installed it to our test instance (with Jenkins ver. 2.121.2 and Bitbucket Branch Source Plugin 2.2.12) ,  added it to two multibranch projects, and ran builds of several branches. These builds did not show up  in  Atlassian's  Bitbucket Server  bug tracker . (Edit: My original comment belongs to JENKINS-36755 instead.)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-36755) Add the ability to switch off notifications.

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-36755  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add the ability to switch off notifications.   
 

  
 
 
 
 

 
 Skip Notifications Trait 1.0.0 works OK here. I installed it to our test instance (with Jenkins ver. 2.121.2 and Bitbucket Branch Source Plugin 2.2.12), added it to two multibranch projects, and ran builds of several branches. These builds did not show up in Bitbucket Server.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-46250) Allow Bitbucket build status text to be overridden

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-46250  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Allow Bitbucket build status text to be overridden   
 

  
 
 
 
 

 
 Skip Notifications Trait 1.0.0 works OK here. I installed it to our test instance (with Jenkins ver. 2.121.2 and Bitbucket Branch Source Plugin 2.2.12), added it to two multibranch projects, and ran builds of several branches. These builds did not show up in Bitbucket Server.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 In my case, git merge was run because of pull request discovery in a multibranch project using Bitbucket Branch Source. Perhaps that is why the environment variable in Jenkinsfile did not affect it. I have now disabled pull request discovery so that I won't have to kill processes on agents.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 I verified that the git-lfs process has GIT_ASKPASS=echo in its environment, even though my Jenkinsfile starts like this: 

 

pipeline {
environment {
// Possible workaround for git-merge hanging in Jenkins
// due to repeated Git LFS credential prompts
GIT_ASKPASS = 'false'
}
 

 So, I cannot use that as a workaround. These repeated credential retries are consuming about 80% CPU time of one hardware thread, too.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.

[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command

[kalle.niemit...@procomp.fi (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kalle Niemitalo commented on  JENKINS-45228  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command   
 

  
 
 
 
 

 
 After "git merge" hangs like this and I abort the build via Jenkins, the git-lfs process keeps running on the Windows agent. IIRC, it keeps asking for credentials and running "git credential reject". I didn't check the environment variables of the processes but it seems freshEnv.put("GIT_ASKPASS", "echo"); in launchCommandIn, which is intended to prevent the build from hanging, isn't fulfilling its purpose. I wonder if it should do freshEnv.put("GIT_ASKPASS", "false"); instead; that might make the build at least fail cleanly. I should try changing my Jenkinsfiles to set that.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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.
For more options, visit https://groups.google.com/d/optout.