[JIRA] (JENKINS-49076) Cannot set custom PATH inside docker container
Title: Message Title Nenad Miksa commented on JENKINS-49076 Re: Cannot set custom PATH inside docker container Any update on this issue? The workaround by Paul Theunissen works, but its very ugly and inpractical for some use cases. 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.187905.1516636297000.9499.1572973020358%40Atlassian.JIRA.
[JIRA] (JENKINS-45129) Unable to scan branches in multibranch plugin when user has two-step verification enabled
Title: Message Title Nenad Miksa commented on JENKINS-45129 Re: Unable to scan branches in multibranch plugin when user has two-step verification enabled For me this now works, as I said earlier - setting it up with the script does the job for me. The original issue referred to not being able to do even that. So I think it can be closed now. Thank you for your support and for the development of the requested feature! 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-54724) ssh-credentials-plugin broken when using ssh-slaves-plugin 1.29.0
Title: Message Title Nenad Miksa commented on JENKINS-54724 Re: ssh-credentials-plugin broken when using ssh-slaves-plugin 1.29.0 This resurfaces back in 1.29.2. Downgrading to 1.29.1 solves the issue for me. 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-45129) Unable to scan branches in multibranch plugin when user has two-step verification enabled
Title: Message Title Nenad Miksa commented on JENKINS-45129 Re: Unable to scan branches in multibranch plugin when user has two-step verification enabled Yes, I am using Bitbucket username. 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-45129) Unable to scan branches in multibranch plugin when user has two-step verification enabled
Title: Message Title Nenad Miksa commented on JENKINS-45129 Re: Unable to scan branches in multibranch plugin when user has two-step verification enabled For me it works if I setup the app password using the groovy script, as described here: https://wiki.jenkins.io/display/JENKINS/Bitbucket+Branch+Source+Plugin#BitbucketBranchSourcePlugin-ConfigurepluginviaGroovyscript However, if I setup the app password using UI, then it is treated as normal password and it doesn't work. Hope this helps... 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-53374) file permissions are lost after unstashing on windows node
Title: Message Title
Nenad Miksa updated an issue
Jenkins / JENKINS-53374
file permissions are lost after unstashing on windows node
Change By:
Nenad Miksa
Consider the following script:{code:java}node( 'macos' ) { sh 'rm -rf *' sh 'echo "int main() { return 0; }" > test.cpp' sh 'mkdir bin && gcc test.cpp -o bin/test' sh "ls -l bin" stash name:'test', includes: "bin/*"}node( 'windows' ) {unstash 'test'stash name:'test2', includes: 'bin/*'}node( 'linux' ) { sh 'rm -rf *' unstash 'test2' sh "ls -l bin"}{code}It produces the following output:{code:java}Started by user Nenad MikšaRunning in Durability level: PERFORMANCE_OPTIMIZED[Pipeline] nodeRunning on macpro2 in /opt/jenkins/workspace/Test[Pipeline] {[Pipeline] sh[Test] Running shell script+ rm -rf bin test.cpp[Pipeline] sh[Test] Running shell script+ echo 'int main() { return 0; }'[Pipeline] sh[Test] Running shell script+ mkdir bin+ gcc test.cpp -o bin/test[Pipeline] sh[Test] Running shell script+ ls -l bintotal 16-rwxr-xr-x 1 pero staff 4248 Aug 31 20:40 test[Pipeline] stashStashed 1 file(s)[Pipeline] }[Pipeline] // node[Pipeline] nodeRunning on Jabba in C:\Jenkins\workspace\Test[Pipeline] {[Pipeline] unstash[Pipeline] stashStashed 1 file(s)[Pipeline] }[Pipeline] // node[Pipeline] nodeRunning on blade in /opt/jenkins/root/workspace/Test[Pipeline] {[Pipeline] sh[Test] Running shell script+ rm -rf test.sh[Pipeline] unstash[Pipeline] sh[Test] Running shell script+ ls -l bintotal 8-rw-r--r-- 1 jenkins users 4248 Aug 31 20:40 test[Pipeline] }[Pipeline] // node[Pipeline] End of PipelineFinished: SUCCESS{code}So, after unstashing the unix binary on windows node and stashing it back, it loses its unix file permissions. Since windows does not have unix file permissions, I would expect that on windows would treat all files in 777 mode, especially after stashing back. In case if you are wondering why is this important to me, here is the rationale:I use Jenkins to build Conan packages of my software. The binaries are first built on various nodes for various platforms (windows, linux, macos, android and ios) and after binaries for every platform have been built successfully, they are all collected on first available node using the stash/unstash mechanism and there they are packaged and uploaded to Conan repository.Due to this issue this causes for binaries that are built on unix nodes lose their file permissions if they are packaged on windows node. A possible workaround would be to enforce packaging on unix node or to perform some partial packaging on nodes that have created the binaries. As these workarounds work for me, I've set priority of this issue as "minor".
[JIRA] (JENKINS-53374) file permissions are lost after unstashing on windows node
Title: Message Title
Nenad Miksa updated an issue
Jenkins / JENKINS-53374
file permissions are lost after unstashing on windows node
Change By:
Nenad Miksa
Consider the following script:{code:java}node( 'macos' ) { sh 'rm -rf *' sh 'echo "int main() { return 0; }" > test.cpp' sh 'mkdir bin && gcc test.cpp -o bin/test' sh "ls -l bin" stash name:'test', includes: "bin/*"}node( 'windows' ) {unstash 'test'stash name:'test2', includes: 'bin/*'}node( 'linux' ) { sh 'rm -rf *' unstash 'test2' sh "ls -l bin"}{code}It produces the following output:{code:java}Started by user Nenad MikšaRunning in Durability level: PERFORMANCE_OPTIMIZED[Pipeline] nodeRunning on macpro2 in /opt/jenkins/workspace/Test[Pipeline] {[Pipeline] sh[Test] Running shell script+ rm -rf bin test.cpp[Pipeline] sh[Test] Running shell script+ echo 'int main() { return 0; }'[Pipeline] sh[Test] Running shell script+ mkdir bin+ gcc test.cpp -o bin/test[Pipeline] sh[Test] Running shell script+ ls -l bintotal 16-rwxr-xr-x 1 pero staff 4248 Aug 31 20:40 test[Pipeline] stashStashed 1 file(s)[Pipeline] }[Pipeline] // node[Pipeline] nodeRunning on Jabba in C:\Jenkins\workspace\Test[Pipeline] {[Pipeline] unstash[Pipeline] stashStashed 1 file(s)[Pipeline] }[Pipeline] // node[Pipeline] nodeRunning on blade in /opt/jenkins/root/workspace/Test[Pipeline] {[Pipeline] sh[Test] Running shell script+ rm -rf test.sh[Pipeline] unstash[Pipeline] sh[Test] Running shell script+ ls -l bintotal 8-rw-r--r-- 1 jenkins users 4248 Aug 31 20:40 test[Pipeline] }[Pipeline] // node[Pipeline] End of PipelineFinished: SUCCESS{code}So, after unstashing the unix binary on windows node and stashing it back, it loses its unix file permissions. Since windows does not have unix file permissions, I would expect that on windows would treat all files in 777 mode, especially after stashing back. In case if you are wondering why is this important to me, here is the rationale explanation :I use Jenkins to build Conan packages of my software. The binaries are first built on various nodes for various platforms (windows, linux, macos, android and ios) and after binaries for every platform have been built successfully, they are all collected on first available node using the stash/unstash mechanism and there they are packaged and uploaded to Conan repository.Due to this issue this causes for binaries that are built on unix nodes lose their file permissions if they are packaged on windows node. A possible workaround would be to enforce packaging on unix node or to perform some partial packaging on nodes that have created the binaries. As these workarounds work for me, I've set priority of this issue as "minor".
[JIRA] (JENKINS-26659) file permissions aren't protected after archive/unarchive
Title: Message Title Nenad Miksa commented on JENKINS-26659 Re: file permissions aren't protected after archive/unarchive I've reported it here: https://issues.jenkins-ci.org/browse/JENKINS-53374 You were correct - it was not the same issue, I just observed the same result on my system, but after creating the minimal reproducing sample, I've seen that it's actually a completely different feature. 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-53374) file permissions are lost after unstashing on windows node
Title: Message Title
Nenad Miksa created an issue
Jenkins / JENKINS-53374
file permissions are lost after unstashing on windows node
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2018-08-31 18:44
Environment:
Jenkins 2.140 Pipeline 2.5
Priority:
Minor
Reporter:
Nenad Miksa
Consider the following script:
node( 'macos' ) {
sh 'rm -rf *'
sh 'echo "int main() { return 0; }" > test.cpp'
sh 'mkdir bin && gcc test.cpp -o bin/test'
sh "ls -l bin"
stash name:'test', includes: "bin/*"
}node( 'windows' ) {
unstash 'test'
stash name:'test2', includes: 'bin/*'
}node( 'linux' ) {
sh 'rm -rf *'
unstash 'test2'
sh "ls -l bin"
}
It produces the following output:
Started by user Nenad Mikša
Running in Durability level: PERFORMANCE_OPTIMIZED
[Pipeline] node
Running on macpro2 in /opt/jenkins/workspace/Test
[Pipeline] {
[Pipeline] sh
[Test] Running shell script
+ rm -rf bin test.cpp
[Pipeline] sh
[Test] Running shell script
+ echo 'int main() { return 0; }'
[Pipeline] sh
[Test] Running shell script
+ mkdir bin
+ gcc test.cpp -o bin/test
[Pipeline] sh
[Test] Running shell script
+ ls -l bin
total 16
-rwxr-xr-x 1 pero staff 4248 Aug 31 20:40 test
[Pipeline] stash
Stashed 1 file(s)
[Pipeline] }
[Pipeline] // node
[Pipeline] node
Running on Jabba in
[JIRA] (JENKINS-26659) file permissions aren't protected after archive/unarchive
Title: Message Title Nenad Miksa reopened an issue The same issue happens with stash/unstash with Jenkins 2.140 and Pipeline 2.5 Jenkins / JENKINS-26659 file permissions aren't protected after archive/unarchive Change By: Nenad Miksa Resolution: Won't Fix Status: Resolved Reopened 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-53115) Failure to parse JUnit after upgrading from 1.104 to 2.2.3
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-53115 Failure to parse JUnit after upgrading from 1.104 to 2.2.3 Issue Type: Bug Assignee: Nikolas Falco Components: xunit-plugin Created: 2018-08-18 08:12 Environment: Jenkins 2.136 Master node is on ArchLinux x64, installed from pacman repository Priority: Major Reporter: Nenad Miksa Here is the exception I get: org.jenkinsci.plugins.xunit.service.TransformerException: The result file '/opt/fast/jenkins/jenkinsData/Executor3/build/ios-jenkins-Release/junit/CoreUtils.xml' for the metric 'JUnit' is not valid. The result file has been skipped. at org.jenkinsci.plugins.xunit.service.XUnitTransformerCallable.invoke(XUnitTransformerCallable.java:112) at org.jenkinsci.plugins.xunit.service.XUnitTransformerCallable.invoke(XUnitTransformerCallable.java:39) at hudson.FilePath.act(FilePath.java:1076) at hudson.FilePath.act(FilePath.java:1059) at org.jenkinsci.plugins.xunit.XUnitProcessor.processTestsReport(XUnitProcessor.java:180) at org.jenkinsci.plugins.xunit.XUnitProcessor.process(XUnitProcessor.java:150) at org.jenkinsci.plugins.xunit.XUnitBuilder.perform(XUnitBuilder.java:114) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:80) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:67) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1$1.call(SynchronousNonBlockingStepExecution.java:50) at hudson.security.ACL.impersonate(ACL.java:290) at
[JIRA] (JENKINS-45129) Unable to scan branches in multibranch plugin when user has two-step verification enabled
Title: Message Title Nenad Miksa assigned an issue to Unassigned Jenkins / JENKINS-45129 Unable to scan branches in multibranch plugin when user has two-step verification enabled Change By: Nenad Miksa Assignee: Nenad Miksa 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-45129) Unable to scan branches in multibranch plugin when user has two-step verification enabled
Title: Message Title Nenad Miksa commented on JENKINS-45129 Re: Unable to scan branches in multibranch plugin when user has two-step verification enabled This issue is still present in v2.2.9. Didn't 2.2.5 suppose to move to Bitbucket API v2? 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-45129) Unable to scan branches in multibranch plugin when user has two-step verification enabled
Title: Message Title Nenad Miksa assigned an issue to Nenad Miksa Jenkins / JENKINS-45129 Unable to scan branches in multibranch plugin when user has two-step verification enabled Change By: Nenad Miksa Assignee: Antonio Muñiz Nenad Miksa 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-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title Nenad Miksa closed an issue as Cannot Reproduce Hi Mark Waite, thank you for pointing that out. I've now explicitely added `honorRefspec: false` to my clone option as a precaution for case if multibranch-pipeline sets it as true. Hopefully I won't have merge before build issues anymore now - If I will, I will reopen this issue. Jenkins / JENKINS-36563 Git plugin does not fetch branch to merge to when merge before build is used Change By: Nenad Miksa Status: Reopened Closed Resolution: Cannot Reproduce Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) --
[JIRA] (JENKINS-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title Nenad Miksa reopened an issue This issue was resolved in v2.5.3 and was not there in v2.6.0, however it reappeared in v3.0.0 and is still present in v3.0.5. Are there any options to tell git from pipeline script to always fetch all? Jenkins / JENKINS-36563 Git plugin does not fetch branch to merge to when merge before build is used Change By: Nenad Miksa Resolution: Fixed Status: Resolved Reopened Assignee: Mark Waite Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title
Nenad Miksa updated an issue
Jenkins / JENKINS-36563
Git plugin does not fetch branch to merge to when merge before build is used
Change By:
Nenad Miksa
Environment:
ArchLinux, Jenkins 2. 13 48 , Git Plugin 2 3 . 5 0 . 2 5 , Git Client Plugin 1 2 . 19 2 . 6 1
I am using MultiBranch Pipeline and performing git cloning like this when I detect in script that this build is building a PullRequest:{code:java} try { checkout([ $class: 'GitSCM', branches: scm.branches, doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations, extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: false, depth: 0, timeout: 60], [$class: 'PruneStaleBranch'], [$class: 'CheckoutOption', timeout: 60], [$class: 'SubmoduleOption', recursiveSubmodules: true, timeout: 60], [$class: 'PreBuildMerge', options: [mergeRemote: 'origin', mergeTarget: targetBranch, fastForwardMode: ffMode]]], submoduleCfg: [], userRemoteConfigs: scm.userRemoteConfigs, browser: [$class: 'BitbucketWeb', repoUrl: 'https://bitbucket.org/microblink/core'] ]) } catch (error) { currentBuild.result = 'FAILURE' echo "ERROR: Cannot perform git checkout due to git error or because branch does not merge cleanly!, Reason: '${error}'" sh 'false' }{code}scm is global variable defined by Multibranch Pipeline plugin and targetBranch is variable containing branch to which pull request is to (in my case this is 'master'). ffMode variable is set to 'FF_ONLY'This used to work two weeks ago, and now it stopped with following error:{code}hudson.plugins.git.GitException: Command "git rev-parse origin/master^{commit}" returned status code 128:stdout: origin/master^{commit}stderr: fatal: ambiguous argument 'origin/master^{commit}': unknown revision or path not in the working tree.Use '--' to separate paths from revisions, like this:'git [...] -- [...]'{code}Indeed, if I cd into jenkins build dir on server and execute this command, I get the same error. Furthermore, If I execute 'git branch -a', I see no branches being fetched.This used to work before, but recently it stopped. Unfortunately, I cannot tell whether it stopped working due to update of jenkins, git plugin or git client plugin - downgrading any of it does not remove the issue. EDIT: This issue was fixed in v2.6.0, but reappeared in v3.0.0 and is still here in v3.0.5.
[JIRA] (JENKINS-33761) Ability to disable "resume" build.
Title: Message Title
Nenad Miksa edited a comment on JENKINS-33761
Re: Ability to disable "resume" build.
[~jglick], unfortunately the bug is not deterministic - usually after restart jobs just hang, but can be killed (with kill of course, rarely works with stop).The shell script which hanged in a way that after resume job could not be killed at all is this: {code:java} sh "curl -s -X POST https://bitbucket.org/site/oauth2/access_token -u \"${getBitbucketOAuthKey()}:${getBitbucketOAuthSecret()}\" -d grant_type=client_credentials | jsawk 'return this.access_token' | tr -d \"\\n\" > accessToken.txt" {code} Script obtains access token for BitBucket API so it can be used later for notifying commit statuses and approving pull request - something that bitbucket branch source plugin does not support (later they added support for that, but it is not configurable to give flexibility we need). I cannot guarantee you that this will trigger the bug, since this shell script is executed for every build we have and only 3 jobs (out of dozens daily) have been executing this script at the time of jenkins restart, which caused them to lock in a way that even kill didn't work.However, it would be better to just fix resuming of jobs - since the original bug report, I have seen much improvements in this field (unix shell scripts now rarely hang after resume, but windows batch script almost always do). As I said, the most problematic are windows batch scripts running cmake-base build of visual studio c++ projects (cmake is used to create visual studio solution and then 'cmake --build . --config Release .' is used to invoke MSBuild builder to build the project). When restart is triggered (on master node, which is linux box) while this build is executing on windows slave, first this batch script is terminated (I guess with some kind of interrupt signal) which causes MSVC to report build as failed (MSVC reports cancelled builds as failures) and after restart this batch script is resumed, but instead of either new build with MSBuild or new call to entire batch script (which should build the project correctly) or continuing with next batch script which is followed after the one which performs the build (which actually collects test results and stashes them so later master node can utilize XUnit publisher plugin to publish test results), the job simply hangs and does nothing indefinitely (until someone logs in and kills it, because stop command is also ignored).
Add Comment
[JIRA] (JENKINS-33761) Ability to disable "resume" build.
Title: Message Title
Nenad Miksa commented on JENKINS-33761
Re: Ability to disable "resume" build.
Jesse Glick, unfortunately the bug is not deterministic - usually after restart jobs just hang, but can be killed (with kill of course, rarely works with stop). The shell script which hanged in a way that after resume job could not be killed at all is this: sh "curl -s -X POST https://bitbucket.org/site/oauth2/access_token -u \"$ {getBitbucketOAuthKey()} :$ {getBitbucketOAuthSecret()} \" -d grant_type=client_credentials | jsawk 'return this.access_token' | tr -d \"\\n\" > accessToken.txt" Script obtains access token for BitBucket API so it can be used later for notifying commit statuses and approving pull request - something that bitbucket branch source plugin does not support (later they added support for that, but it is not configurable to give flexibility we need). I cannot guarantee you that this will trigger the bug, since this shell script is executed for every build we have and only 3 jobs (out of dozens daily) have been executing this script at the time of jenkins restart, which caused them to lock in a way that even kill didn't work. However, it would be better to just fix resuming of jobs - since the original bug report, I have seen much improvements in this field (unix shell scripts now rarely hang after resume, but windows batch script almost always do). As I said, the most problematic are windows batch scripts running cmake-base build of visual studio c++ projects (cmake is used to create visual studio solution and then 'cmake --build . --config Release .' is used to invoke MSBuild builder to build the project). When restart is triggered (on master node, which is linux box) while this build is executing on windows slave, first this batch script is terminated (I guess with some kind of interrupt signal) which causes MSVC to report build as failed (MSVC reports cancelled builds as failures) and after restart this batch script is resumed, but instead of either new build with MSBuild or new call to entire batch script (which should build the project correctly) or continuing with next batch script which is followed after the one which performs the build (which actually collects test results and stashes them so later master node can utilize XUnit publisher plugin to publish test results), the job simply hangs and does nothing indefinitely (until someone logs in and kills it, because stop command is also ignored).
Add Comment
[JIRA] (JENKINS-33761) Ability to disable "resume" build.
Title: Message Title Nenad Miksa edited a comment on JENKINS-33761 Re: Ability to disable "resume" build. [~jglick], I am aware that resuming build is one of the core features of pipeline and that you would very much like it to work by default, however from my experience most of the plugins do not properly support resuming the build (i.e. they have bugs, not that they do not deliberately support it). After restarting the Jenkins (mostly due to plugin updates), I've seen jobs resuming without taking any executors, jobs taking an executor and just waiting something to happen (which never happens , i.e. waiting is infinite ), jobs which do the same thing (that was already done) after being resumed, plugins failing to parse XML test reports after being "resumed" in the middle of the process, jobs that were restarted during perfoming network operations inside shell script which were frozen after resume and could not be stopped in any way (neither with stop nor with kill - we had to manually remove the job from database while jenkins was offline to stop this job from resuming), ...Please be aware that jenkins is also used by software developers that do not develop in Java (which is natively supported by jenkins) and that we do some very weird things in our build scripts to support behaviour and flexibility we need (for example, in my case I need to clone repository on SSD, while one of its submodules must be cloned on rotational disk - such a use case will never be supported by default jenkins scm plugins and I must therefore write my on build script which does that, and improper/buggy resuming of such a script usually makes the executor wait indefinitely for something which never happens, so I must manually kill the build (yes, kill, because stop is also ignored)).For such proper supporting such use cases, there are two ways - either add support in every plugin for every use case (no matter how weird it is) and make it correctly work in all cases, including bug-free resuming build on multi-node heterogenous system - which is nearly impossible, or simply add this simple checkbox saying "disable resuming of build" which will either prevent jenkins to be restarted while build is ongoing (behaviour of freestyle job), or simply fail the build. Yes, failing the build is not technically correct, but it is exactly what is currently happening for us, except after resuming, a engineer needs to log into the jenkins and manually kill the zombie build which only waits and never properly resumes. Add Comment
[JIRA] (JENKINS-33761) Ability to disable "resume" build.
Title: Message Title Nenad Miksa commented on JENKINS-33761 Re: Ability to disable "resume" build. Jesse Glick, I am aware that resuming build is one of the core features of pipeline and that you would very much like it to work by default, however from my experience most of the plugins do not properly support resuming the build (i.e. they have bugs, not that they do not deliberately support it). After restarting the Jenkins (mostly due to plugin updates), I've seen jobs resuming without taking any executors, jobs taking an executor and just waiting something to happen (which never happens), jobs which do the same thing after being resumed, plugins failing to parse XML test reports after being "resumed" in the middle of the process, jobs that were restarted during perfoming network operations inside shell script which were frozen after resume and could not be stopped in any way (neither with stop nor with kill - we had to manually remove the job from database while jenkins was offline to stop this job from resuming), ... Please be aware that jenkins is also used by software developers that do not develop in Java (which is natively supported by jenkins) and that we do some very weird things in our build scripts to support behaviour and flexibility we need (for example, in my case I need to clone repository on SSD, while one of its submodules must be cloned on rotational disk - such a use case will never be supported by default jenkins scm plugins and I must therefore write my on build script which does that, and improper/buggy resuming of such a script usually makes the executor wait indefinitely for something which never happens, so I must manually kill the build (yes, kill, because stop is also ignored)). For such proper supporting such use cases, there are two ways - either add support in every plugin for every use case (no matter how weird it is) and make it correctly work in all cases, including bug-free resuming build on multi-node heterogenous system - which is nearly impossible, or simply add this simple checkbox saying "disable resuming of build" which will either prevent jenkins to be restarted while build is ongoing (behaviour of freestyle job), or simply fail the build. Yes, failing the build is not technically correct, but it is exactly what is currently happening for us, except after resuming, a engineer needs to log into the jenkins and manually kill the zombie build which only waits and never properly resumes. Add Comment
[JIRA] (JENKINS-38419) Unable to detect PullRequest anymore
Title: Message Title
Nenad Miksa created an issue
Jenkins / JENKINS-38419
Unable to detect PullRequest anymore
Issue Type:
Bug
Assignee:
Antonio Muñiz
Components:
bitbucket-branch-source-plugin
Created:
2016/Sep/21 2:06 PM
Environment:
Jenkins v2.23, Bitbucket branch source plugin v1.8
Priority:
Major
Reporter:
Nenad Miksa
This is a regression from v1.7. In v1.7 I could test whether PR is being built with 'env.BRANCH_NAME.startsWith("PR-")', and in v1.8 'env.BRANCH_NAME' is set to name of branch from which pull request originates. This is OK for me, but the I would expect 'env. CHANGE_ID' to be set to non-null and contain information about pull request number. However, in v1.8 CHANGE_ID is null even for pull requests, while BRANCH_NAME contains name of branch for both pull requests and branches. How to detect from script whether PR or branch is being built? I want different build behaviour for PRs and feature branches.
Add Comment
[JIRA] (JENKINS-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title Nenad Miksa commented on JENKINS-36563 Re: Git plugin does not fetch branch to merge to when merge before build is used In v2.6.0 this worked OK and was fixed, but it seems that there is a regression in v3.0.0, as we are experiencing the same bug again after updating to v3.0.0. Reverting back to v2.6.0 solves the problem for us. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-34981) Make valgrind-plugin compatible with pipeline
Title: Message Title Nenad Miksa commented on JENKINS-34981 Re: Make valgrind-plugin compatible with pipeline This is not becoming critical for us. We currently use workaround to start a freestyle job from pipeline just to collect valgrind results and this causes deadlocks if there are no free executors available to collect memcheck results from freestyle job. Is it really so difficult to implement pipeline support? Is there something I could do to help? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-35663) Aborting pipeline build does not work
Title: Message Title Nenad Miksa commented on JENKINS-35663 Re: Aborting pipeline build does not work Our pipeline which causes this behaviour is attached buildCore.groovy common.groovy - you can modify them for your needs to reproduce the issue. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-35663) Aborting pipeline build does not work
Title: Message Title Nenad Miksa updated an issue Jenkins / JENKINS-35663 Aborting pipeline build does not work Change By: Nenad Miksa Attachment: bitbucket.groovy Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-35663) Aborting pipeline build does not work
Title: Message Title Nenad Miksa updated an issue Jenkins / JENKINS-35663 Aborting pipeline build does not work Change By: Nenad Miksa Attachment: bitbucket.groovy Attachment: buildCore.groovy Attachment: common.groovy Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-34981) Make valgrind-plugin compatible with pipeline
Title: Message Title Nenad Miksa commented on JENKINS-34981 Re: Make valgrind-plugin compatible with pipeline Any progress on this? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title Nenad Miksa commented on JENKINS-36563 Re: Git plugin does not fetch branch to merge to when merge before build is used OK, after downgrading to v2.5.0 and wiping the workspace I can confirm that merge before build now works. As you said, the change introduced in v2.5.1 introduced the issue. Any known workarounds (except preventing upgrade of git plugin)? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title Nenad Miksa commented on JENKINS-36563 Re: Git plugin does not fetch branch to merge to when merge before build is used Running git config --get remote.origin.fetch returns +refs/heads/feature/my-feature-branch. I believe this is wrong. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title Nenad Miksa commented on JENKINS-36563 Re: Git plugin does not fetch branch to merge to when merge before build is used In failing repositories, git branch -a returns empty list (I mentioned that in original report). Downgrading git-plugin to 2.5.0 did not help, although I haven't tried wiping the workspace after downgrade. I'll try that ASAP. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title Nenad Miksa updated an issue Jenkins / JENKINS-36563 Git plugin does not fetch branch to merge to when merge before build is used Change By: Nenad Miksa Component/s: workflow-multibranch-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36563) Git plugin does not fetch branch to merge to when merge before build is used
Title: Message Title
Nenad Miksa created an issue
Jenkins / JENKINS-36563
Git plugin does not fetch branch to merge to when merge before build is used
Issue Type:
Bug
Assignee:
Mark Waite
Components:
git-plugin
Created:
2016/Jul/11 9:07 AM
Environment:
ArchLinux, Jenkins 2.13, Git Plugin 2.5.2, Git Client Plugin 1.19.6
Priority:
Blocker
Reporter:
Nenad Miksa
I am using MultiBranch Pipeline and performing git cloning like this when I detect in script that this build is building a PullRequest:
try {
checkout([
$class: 'GitSCM',
branches: scm.branches,
doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: false, depth: 0, timeout: 60], [$class: 'PruneStaleBranch'], [$class: 'CheckoutOption', timeout: 60], [$class: 'SubmoduleOption', recursiveSubmodules: true, timeout: 60], [$class: 'PreBuildMerge', options: [mergeRemote: 'origin', mergeTarget: targetBranch, fastForwardMode: ffMode]]],
submoduleCfg: [],
userRemoteConfigs: scm.userRemoteConfigs,
browser: [$class: 'BitbucketWeb', repoUrl: 'https://bitbucket.org/microblink/core']
])
} catch (error) {
currentBuild.result = 'FAILURE'
echo "ERROR: Cannot
[JIRA] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title Nenad Miksa commented on JENKINS-34788 Re: Build status notification fails with "Enter a valid URL" Thanks! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-33507) Bitbucket Server webhooks and Bitbucket Cloud build status notifications
Title: Message Title Nenad Miksa commented on JENKINS-33507 Re: Bitbucket Server webhooks and Bitbucket Cloud build status notifications I forgot to mention - you need to define functions getBitbucketOAuthKey() and getBitbucketOAuthSecret() which return OAuth key and secret for OAuth consumer. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-34931) Build merge commit instead of PR head
Title: Message Title
Nenad Miksa commented on JENKINS-34931
Re: Build merge commit instead of PR head
Kevin Smets, we have updated our workaround to work correctly, i.e. it can now resolve the PR target. We use curl and jsawk with Bitbucket API to get info about pull request in question. Here is the code:
def getPullRequestID() {
return env.BRANCH_NAME.substring(3)
}
def obtainBitbucketToken() {
try {
echo "Obtaining BitBucket Access Token"
sh "curl -s -X POST https://bitbucket.org/site/oauth2/access_token -u \"${getBitbucketOAuthKey()}:${getBitbucketOAuthSecret()}\" -d grant_type=client_credentials | jsawk 'return this.access_token' | tr -d \"\\n\" > accessToken.txt"
def accessToken = readFile 'accessToken.txt'
echo "BitBucket Token request response: ${accessToken}"
return accessToken
} catch (error) {
echo "Failed to obtain BitBucket access token!"
return null
}
}
def getPullRequestTargetAndSourceCommit(String accessToken, String repository, String pullRequestID) {
try {
sh "curl -s -X GET https://api.bitbucket.org/2.0/repositories/microblink/${repository}/pullrequests/${pullRequestID} -H \"Authorization: Bearer ${accessToken}\" > pullRequestInfo.json"
sh "cat pullRequestInfo.json | jsawk 'return this.source.commit.hash' | tr -d '\\n' > commitID.txt"
sh "cat pullRequestInfo.json | jsawk 'return this.destination.branch.name' | tr -d '\\n' > destinationBranch.txt"
return [commitHash: readFile('commitID.txt'), destinationBranch: readFile('destinationBranch.txt')]
} catch (error) {
echo "Failed to obtain pull request target and source commit. Reason: ${error}"
return null
}
}
This can be used like this:
def accessToken = obtainBitbucketToken()
def pullRequestID = getPullRequestID()
def prInfo = getPullRequestTargetAndSourceCommit(accessToken, repository, pullRequestID)
def targetBranch = 'master'
if (prInfo != null) {
targetBranch = prInfo.destinationBranch
}
This code needs to be executed on unix node which has curl and jsawk tools installed. We tried parsing JSON with Groovy's builtin JsonSlurper, but it kept crashing with serialization errors even when used entirely from within function marked with @NonCPS. The getPullRequestTargetAndSourceCommit method also returns commit hash which can be used to notify build status to BitBucket, as described in this comment: https://issues.jenkins-ci.org/browse/JENKINS-33507?focusedCommentId=261926=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-261926 By using curl to directly communicate with BitBucket API we have additional flexibility, like support for approving/unapproving pull requests and much more.
[JIRA] (JENKINS-35467) Bitbucket Server build status notification in-progress
Title: Message Title Nenad Miksa commented on JENKINS-35467 Re: Bitbucket Server build status notification in-progress In our project we have a workaround for this bug. Check my comment: https://issues.jenkins-ci.org/browse/JENKINS-33507?focusedCommentId=261926=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-261926 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-33507) Bitbucket Server webhooks and Bitbucket Cloud build status notifications
Title: Message Title
Nenad Miksa commented on JENKINS-33507
Re: Bitbucket Server webhooks and Bitbucket Cloud build status notifications
For BitBucket status API notifications, we have the following workaround:
def obtainBitbucketToken() {
try {
echo "Obtaining BitBucket Access Token"
sh "curl -s -X POST https://bitbucket.org/site/oauth2/access_token -u \"${getBitbucketOAuthKey()}:${getBitbucketOAuthSecret()}\" -d grant_type=client_credentials | jsawk 'return this.access_token' | tr -d \"\\n\" > accessToken.txt"
def accessToken = readFile 'accessToken.txt'
echo "BitBucket Token request response: ${accessToken}"
return accessToken
} catch (error) {
echo "Failed to obtain BitBucket access token!"
return null
}
}
def notifyCommit(String accessToken, String commitHash, String repository, String buildKey, boolean inProgress, boolean runTests) {
echo "Notifying commit"
if (accessToken == null) {
echo "Failed to notify commit with null access token!"
return
}
try {
def state = null
def description = null
if (inProgress) {
state = 'INPROGRESS'
description = "Build in progress. Tests will run: ${runTests}"
} else {
if (currentBuild.result == 'SUCCESS') {
state = 'SUCCESSFUL'
if (runTests) {
description = 'Build has succeeded and all tests have passed!'
} else {
description = 'Build has succeeded but tests were not run!'
}
} else {
state = 'FAILED'
if (currentBuild.result == 'UNSTABLE') {
description = 'Build has succeeded, but some tests have failed!'
} else {
description = "Build has failed. Jenkins result is: ${currentBuild.result}"
}
}
}
def payload = "{\"state\": \"${state}\", \"key\": \"Jenkins ${buildKey}\", \"name\": \"Jenkins ${buildKey}\", \"url\": \"${env.BUILD_URL}\", \"description\": \"${description}\"}"
sh "curl -s -X POST https://api.bitbucket.org/2.0/repositories/microblink/${repository}/commit/${commitHash}/statuses/build -H \"Content-Type: application/json\" -H \"Authorization: Bearer ${accessToken}\" -d '${payload}'"
} catch(error) {
echo "There has been an error with notifying BitBucket!. Error: ${error}"
}
}
So, at the beginning of my pipeline script, after checkout and resolving of git commit, I call it this way:
def accessToken = obtainBitbucketToken()
notifyCommit(accessToken, commitHash, repository, keyPullRequestBuild, true, runTests) // runTests is variable in my pipeline telling me whether tests should be run
After the build finishes, I just need to call:
def accessToken =
[JIRA] (JENKINS-35702) Hard-killing a pipeline build removes executors from master node
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35702 Hard-killing a pipeline build removes executors from master node Issue Type: Bug Assignee: Manuel Recena Soto Components: workflow-multibranch-plugin Created: 2016/Jun/14 2:39 PM Priority: Blocker Reporter: Nenad Miksa Lots of builds keep hanging for us, so we need to use hard kill feature. Unfortunately, when hard-killing a job it causes all executors from master node to disappear and no new builds can ever perform. Restart of Jenkins server solves the issue. Add Comment
[JIRA] [bitbucket-branch-source-plugin] (JENKINS-33507) Bitbucket Server webhooks and Bitbucket Cloud build status notifications
Title: Message Title Nenad Miksa commented on JENKINS-33507 Re: Bitbucket Server webhooks and Bitbucket Cloud build status notifications We actually have solved this way: we created a webhook on BitBucket which every time there is a push to repository or pull request is created or updated, it calls this URL: http://jenkins.server/job/MyPipelineJob/build MyPipelineJob is multibranch pipeline job which only enumerates changes in pull requests and feature branches and triggers builds if necessary. However, we are missing Build status badges from BitBucket BuildStatus API. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-branch-source-plugin] (JENKINS-35674) Pull requests not rebuilt when destination commit changes
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35674 Pull requests not rebuilt when destination commit changes Issue Type: Bug Assignee: Antonio Muñiz Components: bitbucket-branch-source-plugin Created: 2016/Jun/13 2:05 PM Priority: Major Reporter: Nenad Miksa When there is a pull request from feature branch to master branch and someone else either commits something directly to master or merges another pull request, the pull request is not rebuilt - bitbucket-branch-source plugin only checks PR HEAD, but not its destination. PR should be rebuilt when either HEAD or DESTINATION changes. Add Comment
[JIRA] [build-pipeline-plugin] (JENKINS-35663) Aborting pipeline build does not work
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35663 Aborting pipeline build does not work Issue Type: Bug Assignee: Manuel Recena Soto Components: build-pipeline-plugin, workflow-multibranch-plugin Created: 2016/Jun/13 8:10 AM Priority: Blocker Reporter: Nenad Miksa Aborting job that has multiple parallel threads keeps one or more threads lingering, while consuming the executor. I do not see any way of killing those threads and aborting the build. Here is the thread dump: Thread #94 at DSL.dir(Native Method) at WorkflowScript.run(WorkflowScript:246) at DSL.node(Native Method) at WorkflowScript.run(WorkflowScript:222) Add Comment
[JIRA] [build-monitor-plugin] (JENKINS-35662) Show Executor status
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35662 Show Executor status Issue Type: New Feature Assignee: Unassigned Components: build-monitor-plugin Created: 2016/Jun/13 7:53 AM Priority: Minor Reporter: Nenad Miksa It would be nice to display current status of all Jenkins executors somewhere in Build monitor. Add Comment This message was sent by Atlassian JIRA
[JIRA] [bitbucket-branch-source-plugin] (JENKINS-33507) Bitbucket Server webhooks and Bitbucket Cloud build status notifications
Title: Message Title Nenad Miksa commented on JENKINS-33507 Re: Bitbucket Server webhooks and Bitbucket Cloud build status notifications Well, if webhook autoregistering is problematic, build status API implementation would be enough for us at first. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [workflow-multibranch-plugin] (JENKINS-35655) Add ability to define name of Jenkinsfile
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35655 Add ability to define name of Jenkinsfile Issue Type: Improvement Assignee: Manuel Recena Soto Components: workflow-multibranch-plugin Created: 2016/Jun/12 7:29 PM Priority: Minor Reporter: Nenad Miksa Pipeline multibranch plugin currently always searches for Jenkinsfile. I would like to be able to configure name of the Jenkinsfile. That would enable having different jobs running different builds on same repository. For example, I would have one job running script called Jenkinsfile-quick which would build every commit immediately after push and one job running script called Jenkinsfile-memcheck which would preform valgrind memory analysis every night for every branch. Add Comment
[JIRA] [bitbucket-branch-source-plugin] (JENKINS-34931) Build merge commit instead of PR head
Title: Message Title
Nenad Miksa commented on JENKINS-34931
Re: Build merge commit instead of PR head
Kevin Smets, its kind of hardcoded with forward compatibility with current bug in bitbucket branch source plugin :
// hardcoded global variable
def targetBranch = "master"
// then later in node before doing a checkout:
if(env.CHANGE_TARGET != null) {
targetBranch = env.CHANGE_TARGET
}
Here is the entire workaround, which uses merge before build when building pull request and also using different fastforward strategies based on global nonFFBranches set which is hardcoded in Jenkinsfile (it would be nice to be able to configure that in plugin settings):
node {
if(env.BRANCH_NAME.startsWith("PR-")) {
if(env.CHANGE_TARGET != null) {
targetBranch = env.CHANGE_TARGET
}
echo "Source branches: ${scm.branches[0].name}"
def ffMode = 'FF_ONLY'
if(nonFFBranches.contains(scm.branches[0].name)) {
ffMode = 'NO_FF'
}
// do a full clone with merge before build when building pull request
checkout([
$class: 'GitSCM',
branches: scm.branches,
doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: false, depth: 0, timeout: 60], [$class: 'PruneStaleBranch'], [$class: 'CheckoutOption', timeout: 60], [$class: 'PreBuildMerge', options: [mergeRemote: 'origin', mergeTarget: targetBranch, fastForwardMode: ffMode]]],
submoduleCfg: [],
userRemoteConfigs: scm.userRemoteConfigs,
browser: [$class: 'BitbucketWeb', repoUrl: 'https://bitbucket.org/microblink/core']
])
} else {
// do a shallow clone when building feature branch HEAD
checkout([
$class: 'GitSCM',
branches: scm.branches,
doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: true, depth: 1, timeout: 60], [$class: 'PruneStaleBranch'], [$class: 'CheckoutOption', timeout: 60]],
submoduleCfg: [],
userRemoteConfigs: scm.userRemoteConfigs,
browser: [$class: 'BitbucketWeb', repoUrl: 'https://bitbucket.org/microblink/core']
])
}
}
This workaround requires approval of certain methods in In-Process Script Approval Jenkins settings (namely, access to scm variable getters).
[JIRA] [workflow-plugin] (JENKINS-33022) Allow Git shallow clone in Multibranch pipeline
Title: Message Title Nenad Miksa commented on JENKINS-33022 Re: Allow Git shallow clone in Multibranch pipeline OK, solved by adding permission in In Process Script Approval options. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [workflow-plugin] (JENKINS-33022) Allow Git shallow clone in Multibranch pipeline
Title: Message Title Nenad Miksa commented on JENKINS-33022 Re: Allow Git shallow clone in Multibranch pipeline Maciej Nowak, your trick causes following exception on my side: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method hudson.plugins.git.GitSCM getBranches Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [workflow-multibranch-plugin] (JENKINS-35651) Cleanup workspace folders on job removal
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35651 Cleanup workspace folders on job removal Issue Type: Bug Assignee: Manuel Recena Soto Components: workflow-multibranch-plugin Created: 2016/Jun/12 2:28 PM Priority: Critical Reporter: Nenad Miksa When feature branch has been deleted or pull request merged, the job accompanying it is correctly removed, however its workspace remains on disk, wasting valuable disk space. Our builds are large (several gigabytes per build) so it is very important for us to cleanup workspace as soon as job is removed. Add Comment
[JIRA] [workflow-plugin] (JENKINS-30744) multibranch issues if branch contains /
Title: Message Title Nenad Miksa commented on JENKINS-30744 Re: multibranch issues if branch contains / We are also having this issue and are not using Maven at all. We are invoking NDK-build directly from shell and apparently ndk-build cannot work with paths containing %. Also happens when invoking MSBuild. We are currently using trick to allocate a new workspace with %2F replaced with _, however when job is finally removed (after pull request has been merged and branch deleted), the workspace remains, wasting valuable disk space. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [workflow-plugin] (JENKINS-33761) Ability to disable "resume" build.
Title: Message Title Nenad Miksa commented on JENKINS-33761 Re: Ability to disable "resume" build. Well, in my case I have 7 parallel tasks running heavy shell scripts (scripts run cmake builds and ctest tests). Resuming build after restart starts the scripts from the beginning (which is basically the same as starting the whole job anew) and the worst part is that although 7 parallel branches are being executed, all executors are free, thus making possible for Jenkins to trigger another build and hog up the server resources. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-branch-source-plugin] (JENKINS-35650) Use BitBucket CI API for displaying build status
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35650 Use BitBucket CI API for displaying build status Issue Type: New Feature Assignee: Antonio Muñiz Components: bitbucket-branch-source-plugin Created: 2016/Jun/12 1:22 PM Priority: Major Reporter: Nenad Miksa Currently after commit has been built, comment is added to the commit telling whether build was successful or not. For pull requests build no feedback is given at all (not even comment). It would be much better if BitBucket Build Status API (https://blog.bitbucket.org/2015/11/18/introducing-the-build-status-api-for-bitbucket-cloud/) would be used for defining that commit or pull request build is either INPROGRESS, SUCCESSFUL or FAILED. Add Comment
[JIRA] [bitbucket-branch-source-plugin] (JENKINS-35649) Append pull request name to spawned job name
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35649 Append pull request name to spawned job name Issue Type: Improvement Assignee: Antonio Muñiz Components: bitbucket-branch-source-plugin Created: 2016/Jun/12 1:19 PM Priority: Trivial Reporter: Nenad Miksa Currently, when a pull request is being built, a job named 'PR-number' appears (for example: 'PR-239'). It would be much more user friendly to also append pull request name, especially when Build Monitor (https://wiki.jenkins-ci.org/display/JENKINS/Build+Monitor+Plugin) is being used on office wall. This would then name jobs like: 'PR-293: My pull request name'. Add Comment
[JIRA] [bitbucket-branch-source-plugin] (JENKINS-33701) Add SCM Repository browser support to Multi-branch project
Title: Message Title Nenad Miksa commented on JENKINS-33701 Re: Add SCM Repository browser support to Multi-branch project We tried enabling this feature from Jenkinsfile by mutating global scm variable by adding browser property to it, but unfortunately this failed because scm variable is immutable. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-branch-source-plugin] (JENKINS-33865) Double Build on Multibranch Pipeline with open PR
Title: Message Title Nenad Miksa commented on JENKINS-33865 Re: Double Build on Multibranch Pipeline with open PR If JENKINS-34931 is fixed, then this will not be same anymore - the push would build feature branch HEAD, and pull request build would build merge commit. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-branch-source-plugin] (JENKINS-34931) Build merge commit instead of PR head
Title: Message Title
Nenad Miksa commented on JENKINS-34931
Re: Build merge commit instead of PR head
We also need this feature. Currently we have a workaround which creates a local merge commit if env.BRANCH_NAME.startsWith("PR-"). It would be better if this is done automatically.
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
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] [git-plugin] (JENKINS-35648) Aborting thread doing git operation leaves repository in unclean state
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35648 Aborting thread doing git operation leaves repository in unclean state Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2016/Jun/12 1:03 PM Environment: Jenkins v2.8 Priority: Minor Reporter: Nenad Miksa I have a build in which some git checkout needs to be done on every node under parallel block. If parallel has failFast: true, then when one parallel branch fails, it immediately kills other branches. If a branch was killed while git clone or git checkout operation was being in progress, then index.lock or shallow.lock (due to shallow clone) remains on windows slave and next build fails because git repository has remained locked. Add Comment
[JIRA] [workflow-multibranch-plugin] (JENKINS-35647) Unable to abort parallel pipeline when failfast is used
Title: Message Title Nenad Miksa created an issue Jenkins / JENKINS-35647 Unable to abort parallel pipeline when failfast is used Issue Type: Bug Assignee: Manuel Recena Soto Components: workflow-multibranch-plugin Created: 2016/Jun/12 12:45 PM Environment: Jenkins v2.8 Priority: Minor Reporter: Nenad Miksa I've got a Jenkinsfile which first prepares 7 difficult tasks and then calls them in parallel on 7 executors (5 linux builds with different configurations and 2 windows builds). I also use failFast: true to ensure when any of the branches fails the whole build would fail, without waiting for other branches to complete. However, when one branch fails I can see that all branches in log output get "branch failed", however even though all branches have completed, Jenkins still shows my build as being in progress. Even worse, if I click the x button to abort the build, nothing happens (the build continues to run, even though no executor is used and nothing is really happening). If I restart the Jenkins, then this build is resumed after restart, however no executor is consumed and nothing really happens, except Jenkins displays this build as being in progress. Here is the thread dump of a zombie build which failed long time ago, yet Jenkins still displays it as "in progress", even though no
[JIRA] [bitbucket-build-status-notifier-plugin] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title Nenad Miksa commented on JENKINS-34788 Re: Build status notification fails with "Enter a valid URL" Thank you for enabling the logging - I figured out the problem. The BitBucket API does not allow server names without dot. So while http://rambo/jenkins/job/AndroidCore/687/ was deemed as invalid URL, http://rambo.local/jenkins/job/AndroidCore/687/ was a valid URL. After all it was not bug in plugin - it was a bug in configuration on my server. Just a hint for future - if possible, please write somewhere (in documentation or setup guide) that server name should be a fully qualified name. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-build-status-notifier-plugin] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title
Nenad Miksa commented on JENKINS-34788
Re: Build status notification fails with "Enter a valid URL"
Hi Antonio Mansilla,
I've finally received the update with logging enabled. Here are the logs of request and response:
Jun 06 09:29:38 rambo jenkins[747]: Jun 06, 2016 9:29:38 AM org.jenkinsci.plugins.bitbucket.BitbucketBuildStatusNotifier notifyBuildStatus Jun 06 09:29:38 rambo jenkins[747]: INFO: This request was sent: { Jun 06 09:29:38 rambo jenkins[747]: "state": "INPROGRESS", Jun 06 09:29:38 rambo jenkins[747]: "key": "2a8f71244f064b1edc24a179661da25f", Jun 06 09:29:38 rambo jenkins[747]: "url": "http://rambo/jenkins/job/AndroidCore/687/", Jun 06 09:29:38 rambo jenkins[747]: "name": "AndroidCore #687" Jun 06 09:29:38 rambo jenkins[747]: }
Jun 06 09:29:38 rambo jenkins[747]: Jun 06, 2016 9:29:38 AM org.jenkinsci.plugins.bitbucket.BitbucketBuildStatusNotifier notifyBuildStatus Jun 06 09:29:38 rambo jenkins[747]: INFO: This response was received: {"error": {"fields": {"url": ["Enter a valid URL."]}
, "message": "Bad request"}}
After cancelling the build:
Jun 06 09:30:02 rambo jenkins[747]: INFO: Bitbucket notify on finish Jun 06 09:30:03 rambo jenkins[747]: Jun 06, 2016 9:30:03 AM org.jenkinsci.plugins.bitbucket.BitbucketBuildStatusNotifier notifyBuildStatus Jun 06 09:30:03 rambo jenkins[747]: INFO: This request was sent: { Jun 06 09:30:03 rambo jenkins[747]: "state": "FAILED", Jun 06 09:30:03 rambo jenkins[747]: "key": "2a8f71244f064b1edc24a179661da25f", Jun 06 09:30:03 rambo jenkins[747]: "url": "http://rambo/jenkins/job/AndroidCore/687/", Jun 06 09:30:03 rambo jenkins[747]: "name": "AndroidCore #687" Jun 06 09:30:03 rambo jenkins[747]: }
Jun 06 09:30:03 rambo jenkins[747]: Jun 06, 2016 9:30:03 AM org.jenkinsci.plugins.bitbucket.BitbucketBuildStatusNotifier notifyBuildStatus Jun 06 09:30:03 rambo jenkins[747]: INFO: This response was received: {"error": {"fields": {"url": ["Enter a valid URL."]}
, "message": "Bad request"}} Jun 06 09:30:03 rambo jenkins[747]: Jun 06, 2016 9:30:03 AM org.jenkinsci.plugins.bitbucket.BitbucketBuildStatusNotifier perform Jun 06 09:30:03 rambo jenkins[747]: INFO: Bitbucket notify on finish succeeded
Hopefully this can help debugging the issue.
Add Comment
[JIRA] [bitbucket-build-status-notifier-plugin] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title Nenad Miksa commented on JENKINS-34788 Re: Build status notification fails with "Enter a valid URL" Thank you a lot, Antonio Mansilla. I am looking forward to being able to debug that issue. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-build-status-notifier-plugin] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title Nenad Miksa commented on JENKINS-34788 Re: Build status notification fails with "Enter a valid URL" Hi Antonio! I can confirm that calling BitBucket with curl as you explained works correctly (I've tried issuing the request from both my laptop and server where Jenkins is installed). When I put some random string which is not in URL form in field "url", then I get the same error as observed in jenkins log. Is there a way for me to enable logging which will show me what is the value plugin puts in "url" field before issuing a request? Btw, one side question: how does plugin perform when I have option "merge before build" enabled in my Git plugin? I've tried issuing a curl request with merge commit created before build and Bitbucket responded with "Changeset not found.". Does in this case plugin send the commit ID of the original commit (before making a merge)? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-build-status-notifier-plugin] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title Nenad Miksa commented on JENKINS-34788 Re: Build status notification fails with "Enter a valid URL" Hi Antonio, Jenkins plugin manager tells me that v1.2.0 is being used. I am keeping all my plugins up to date with the exception of "Bitbucket Pullrequest Builder Plugin" which I keep on 1.4.7 since every version after it causes infinite rebuilds of my pull requests (I've already issued the ticket to the author, yet it is still not fixed in 1.4.18). Is there any debug log I can enable to help you find a problem? Can you add logging of the URL to which you are sending request? Currently only server response is logged. I would like to see the entire request and repeat it from commandline with curl - it may be possible that error is due to my firewall configuration. Regards, Nenad Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-build-status-notifier-plugin] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title Nenad Miksa commented on JENKINS-34788 Re: Build status notification fails with "Enter a valid URL" Hi Antonio. What is a "valid URL"? I've tried setting following URLs as "Callback URL" of OAuth consumer, none of them worked: http://141.138.8.191:54321/jenkins http://141.138.8.191:54321 http://bitbucket:keyForBitbucketUserOnJenkinsServer@141.138.8.191:54321/jenkins (this one is used for notifying Jenkins that there was a push into a repository) For security reason, 141.138.8.191:54321 is accessible only from these IP ranges: 131.103.20.160/27, 165.254.145.0/26 and 104.192.143.0/24 (as documented here: https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html) In Manage Jenkins -> Jenkins Location -> Jenkins URL the set URL is: http://192.168.100.234/jenkins (this URL is accessible only from LAN - not from public Internet). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-build-status-notifier-plugin] (JENKINS-34788) Build status notification fails with "Enter a valid URL"
Title: Message Title
Nenad Miksa created an issue
Jenkins / JENKINS-34788
Build status notification fails with "Enter a valid URL"
Issue Type:
Bug
Assignee:
Antonio Mansilla
Components:
bitbucket-build-status-notifier-plugin
Created:
2016/May/13 9:14 AM
Environment:
Jenkins v2.2 on ArchLinux
Priority:
Major
Reporter:
Nenad Miksa
I've setup my environment as described in this video: https://www.youtube.com/watch?v=uu5XcU4EPzQ
However, when build starts and finishes, I don't see the status on BitBucket commits. In Jenkins log I can see following messages:
May 13 10:57:18 rambo jenkins[743]: INFO: Bitbucket notify on start May 13 10:57:19 rambo jenkins[743]: May 13, 2016 10:57:19 AM org.jenkinsci.plugins.bitbucket.BitbucketBuildStatusNotifier notifyBuildStatus May 13 10:57:19 rambo jenkins[743]: INFO: This response was received:{"error": {"fields": {"url": ["Enter a valid URL."]}
, "message": "Bad request"}} May 13 10:57:19 rambo jenkins[743]: May 13, 2016 10:57:19 AM org.jenkinsci.plugins.bitbucket.BitbucketBuildStatusNotifier prebuild May 13 10:57:19 rambo jenkins[743]: INFO: Bitbucket notify on start succeeded
Any idea what has been configured wrong?
Note: our
[JIRA] [bitbucket-pullrequest-builder-plugin] (JENKINS-31680) Use new bitbucket api to set if build success instead of add a comment
Title: Message Title Nenad Miksa commented on JENKINS-31680 Re: Use new bitbucket api to set if build success instead of add a comment It appears that global settings I found were for Bitbucket Approve plugin, not for Bitbucket pull request builder plugin. I still do not get Bitbucket statuses on build start. From log I can see that POST was sent, but in log I cannot see Bitbucket's response. If I try to reproduce the call with Postman, I get 403 "CSRF verification failed.". BitBucket API suggests using OAuth, and settings for plugin allow entering only BasicAuth username and password (if user has two-step authentication enabled, then plugin does not work at all). Is there a way to see what was returned from server? There are no exceptions in the log. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-pullrequest-builder-plugin] (JENKINS-31680) Use new bitbucket api to set if build success instead of add a comment
Title: Message Title Nenad Miksa commented on JENKINS-31680 Re: Use new bitbucket api to set if build success instead of add a comment This is now even worse as with 1.4.7 because there is no notification at all that build of pull request has finished. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-pullrequest-builder-plugin] (JENKINS-31680) Use new bitbucket api to set if build success instead of add a comment
Title: Message Title Nenad Miksa commented on JENKINS-31680 Re: Use new bitbucket api to set if build success instead of add a comment Does not seem to work with 1.4.8. The build started, but neither a comment nor a build status was added to pull request that is being built. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-pullrequest-builder-plugin] (JENKINS-31680) Use new bitbucket api to set if build success instead of add a comment
Title: Message Title Nenad Miksa commented on JENKINS-31680 Re: Use new bitbucket api to set if build success instead of add a comment We are using Jenkins 1.642. I believe this is the newest Jenkins. Is any special configuration required? We retained the same job configuration as it was with 1.4.7. We simply updated all Jenkins plugins... Can I provide some logs that might be helpful? If yes, which one? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-pullrequest-builder-plugin] (JENKINS-31680) Use new bitbucket api to set if build success instead of add a comment
Title: Message Title Nenad Miksa commented on JENKINS-31680 Re: Use new bitbucket api to set if build success instead of add a comment We also noticed that with 1.4.8 each pull request triggers build multiple times. I will open a new issue for that. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-pullrequest-builder-plugin] (JENKINS-31680) Use new bitbucket api to set if build success instead of add a comment
Title: Message Title Nenad Miksa commented on JENKINS-31680 Re: Use new bitbucket api to set if build success instead of add a comment OK, I've found new variables in global configuration pane. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [bitbucket-pullrequest-builder-plugin] (JENKINS-31680) Use new bitbucket api to set if build success instead of add a comment
Title: Message Title Nenad Miksa commented on JENKINS-31680 Re: Use new bitbucket api to set if build success instead of add a comment I've upvoted your issue. I haven't seen any new variables after updating to 1.4.8. I still have (as I had): 'Cron', 'Bitbucket BasicAuth Username', 'Bitbucket BasicAuth Password', 'RepositoryOwner', 'RepositoryName', 'CI Identifier', 'CI Name', 'CI Skip Phrases', 'Rebuild if destination branch changes?', 'Approve if build success?'. Am I not seeing something? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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.
