[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y)Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less...{code:java}// library importssharedPipeline(){code}vars/sharedPipeline.groovy{code:java}def call() { throttle(['throttle-category']) {sharedPipelineInner() }}{code}vars/sharedPipelineInner.groovy{code:java}def call() { pipeline { agent { label 'mylabel' } stages {stage('first') { steps { sleep 60 }} }}{code} I did try to simply shift the pipeline config into a {{def}} within the original file, but that did not work.This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this. Edit - Then again, the title says _entire build_ so maybe this solution does apply and the example in the body does not. [~anthonymastrean], can you comment?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y)Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less...{code:java}// library importssharedPipeline(){code}vars/sharedPipeline.groovy{code:java}def call() { throttle(['throttle-category']) {sharedPipelineInner() }}{code}vars/sharedPipelineInner.groovy{code:java}def call() { pipeline { agent { label 'mylabel' } stages {stage('first') { steps { sleep 60 }} }}{code} I did try to simply shift the pipeline config into a {{def}} within the original file, but that did not work. This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y)Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less... {code:java}// library imports sharedPipeline() {code} vars/sharedPipeline.groovy{code:java}def call() { throttle(['throttle-category']) {sharedPipelineInner() }}{code}vars/sharedPipelineInner.groovy{code:java}def call() { pipeline { agent { label 'mylabel' } stages {stage('first') { steps { sleep 60 }} }}{code} This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
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
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y) Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less... sharedPipeline() vars/sharedPipeline.groovy{code:java}def call() { throttle(['throttle-category']) {sharedPipelineInner() }}{code}vars/sharedPipelineInner.groovy{code:java}def call() { pipeline { agent { label 'mylabel' } stages {stage('first') { steps { sleep 60 }} }}{code} This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
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
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y) Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less... sharedPipeline() vars/sharedPipeline.groovy{code:java}def call() { throttle(['throttle-category']) {sharedPipelineInner() }}{code}vars/sharedPipelineInner.groovy{code:java}def call() { pipeline { agent { label 'mylabel' } stages {stage('first') { steps { sleep 60 }} }}{code} This way, no {{Jenkinsfile}} will need to be updated and they will all be throttled for free. This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
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
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y) Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less... sharedPipeline() vars/sharedPipeline.groovy{code:java}def call() { throttle(['throttle-category']) { sharedPipelineInner() }}{code}vars/sharedPipelineInner.groovy{code:java}def call() { pipeline { agent { label 'mylabel' } stages {stage('first') { steps { sleep 60 }} }}{code} This way, no {{Jenkinsfile}} will need to be updated and they will all be throttled for free. This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
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
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y) Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less... sharedPipeline() vars/sharedPipeline.groovy{code:java}def call() { throttle(['throttle-category']) { sharedPipelineInner() }}{code}vars/sharedPipelineInner.groovy{code:java}def call() { pipeline { agent { label 'mylabel' } stages {stage('first') { steps {sleep 60 } }} }}{code} This way, no {{Jenkinsfile}} will need to be updated and they will all be throttled for free. This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
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
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y) Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less... sharedPipeline() vars/sharedPipeline.groovy ``` {code:java} def call() { throttle(['throttle-category']) { sharedPipelineInner() } } {code } ``` vars/sharedPipelineInner.groovy {code:java} def call() { pipeline { agent { label 'mylabel' } stages { stage('first') { steps { sleep 60 } } } } } {code } This way, no {{Jenkinsfile}} will need to be updated and they will all be throttled for free. This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
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
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G edited a comment on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning.[~marcus_phi], I'll second your comment/excitement on finally having a solution to this mystery. (flag)[~metamilk], thank you so much! (y) Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by [~metamilk] and here is a little more on how I think I'll `throttle` in our builds by renaming {{sharedPipeline}} to {{sharedPipelineInner}} and having {{sharedPipeline}} wrap the throttle category around the {{sharedPipeline()}} call. This way, I don't need to update 100+ repositories * number of branches. The current {{Jenkinsfile}} looks like this more or less...sharedPipeline()vars/sharedPipeline.groovy ``` def call() {throttle(['throttle-category']) { { sharedPipelineInner() } } ``` vars/sharedPipelineInner.groovydef call() {pipeline {agent { label 'mylabel' } stages {stage('first') \ {steps { { sleep 60 } }}}} This way, no {{Jenkinsfile}} will need to be updated and they will all be throttled for free. This defect asks for {{throttle}} within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
[JIRA] (JENKINS-45140) Add support of throttling of the entire build in Declarative Pipeline
Title: Message Title
Jeff G commented on JENKINS-45140
Re: Add support of throttling of the entire build in Declarative Pipeline
I honestly did not have much hope when I saw this issue having been updated in my e-mail this morning. Marcus Philip, I'll second your comment/excitement on finally having a solution to this mystery. Dmitry Mamchur, thank you so much! Our team already has our declarative and scripted pipelines largely live in libraries. I gave a couple attempts to implement the throttle as described by Dmitry Mamchur and here is a little more on how I think I'll `throttle` in our builds by renaming sharedPipeline to sharedPipelineInner and having sharedPipeline wrap the throttle category around the sharedPipeline() call. This way, I don't need to update 100+ repositories * number of branches. The current Jenkinsfile looks like this more or less... sharedPipeline() vars/sharedPipeline.groovy def call() { throttle(['throttle-category']) { sharedPipelineInner() } } vars/sharedPipelineInner.groovy def call() { pipeline { agent { label 'mylabel' } stages { stage('first') { steps { sleep 60 } } } } } This way, no Jenkinsfile will need to be updated and they will all be throttled for free. This defect asks for throttle within a step, which this solution does not provide, so I guess it will need to stay open. The docs for the plugin should be updated, for sure, with an example like this.
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
[JIRA] (JENKINS-48933) Unstoppable Multibranch Pipeline Scan
Title: Message Title Jeff G commented on JENKINS-48933 Re: Unstoppable Multibranch Pipeline Scan Same issue. Does anyone have a way to abort these? I tried using Scriptler as though it were a build but could not find the right combination. 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.187738.1516006604000.7754.1571136420656%40Atlassian.JIRA.
[JIRA] (JENKINS-44822) bindName and bindPassword not being displayed when created via Groovy
Title: Message Title Jeff G edited a comment on JENKINS-44822 Re: bindName and bindPassword not being displayed when created via Groovy Thank you [~kpsimoulis] for the work around! This does switch you from a single domain to custom domain, but it works. 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-44822) bindName and bindPassword not being displayed when created via Groovy
Title: Message Title Jeff G commented on JENKINS-44822 Re: bindName and bindPassword not being displayed when created via Groovy Thank you Konstantinos Psimoulis for the work around! This does switch you from a single domain to custom domain, but it works. 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-50420) Class-exception in Build Monitor Plugin with Groovy Postbuild Plugin 2.4
Title: Message Title Jeff G commented on JENKINS-50420 Re: Class-exception in Build Monitor Plugin with Groovy Postbuild Plugin 2.4 +1, still a problem on LTS 2.107.2. 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-38998) Cannot trigger pipeline job
Title: Message Title Jeff G commented on JENKINS-38998 Re: Cannot trigger pipeline job Tiejun Sha that won't work in a MultiJob Phase unfortunately. it definitely works as a single build step, though. 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-49121) Ability to skip stages and preserve build history
Title: Message Title Jeff G commented on JENKINS-49121 Re: Ability to skip stages and preserve build history Using declarative pipeline, we have when expressions on the stages to skip certain stages (e.g. publishing artifacts when it is a pull request build). The stage still appears in the stage view but is gray. This might work for you if you use declarative pipeline. 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-41519) Post stages should have well defined order
Title: Message Title Jeff G commented on JENKINS-41519 Re: Post stages should have well defined order +1 for this. Just got bit because you can't use archiveArtifacts in a post:success if you use cleanWs in post:always because post:always will clean up the artifacts you want to archive. 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-38998) Cannot trigger pipeline job
Title: Message Title Jeff G commented on JENKINS-38998 Re: Cannot trigger pipeline job (Currently running LTS 2.73.1) Pipeline jobs are definitely executable by the Parameterized Trigger Plugin. However, they show as "Unresolved" in the Job page. While that might be concerning to the Job homepage viewer, the only loss of functionality is being able to link to the job being triggered by the parent. This is contrary to the MultiJob plugin which DOES NOT drive Pipeline jobs, period. For the MultiJob plugin, it IS a loss of functionality. Also, if you use Folder / Job / Branch, you can list it as such... for example, the job to trigger could be OrgScanFoo/RepoBar/BranchBaz 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-48461) Under "Add Parameters" for each job, include option for previous parameters (i.e. last successful build paramters)
Title: Message Title Jeff G commented on JENKINS-48461 Re: Under "Add Parameters" for each job, include option for previous parameters (i.e. last successful build paramters) Just ran across this enhancement and thought I would provide you a potential work around. On our Jenkins, we had implemented a Groovy Postbuild Action which saved the parameter used values as the job's default parameter whenever it were successful. That sounds like what you are looking to do. I think your ask is a more generic one, not really specific to the Multi-job plugin so I doubt they will address it. I attached the script for your reference. It also adds a tag to the build when the parameters change including a popup for the old/new values. 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-48461) Under "Add Parameters" for each job, include option for previous parameters (i.e. last successful build paramters)
Title: Message Title Jeff G updated an issue Jenkins / JENKINS-48461 Under "Add Parameters" for each job, include option for previous parameters (i.e. last successful build paramters) Change By: Jeff G Attachment: SaveParameterValuesAsDefault.groovy 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-41065) Add configuration to require confirmation to cancel job
Title: Message Title Jeff G updated an issue Jenkins / JENKINS-41065 Add configuration to require confirmation to cancel job Change By: Jeff G Summary: Add confgiuration configuration to require confirmation to cancel job 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-41065) Add confgiuration to require confirmation to cancel job
Title: Message Title Jeff G updated an issue Jenkins / JENKINS-41065 Add confgiuration to require confirmation to cancel job Change By: Jeff G Summary: Add permission confgiuration to require confirmation to cancel job 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-41065) Add permission to require confirmation to cancel job
Title: Message Title Jeff G commented on JENKINS-41065 Re: Add permission to require confirmation to cancel job I appreciate your feedback on my request. I would be happy to have a global configuration which indicated if the confirmation is needed system wide. Our Jenkins is internally facing and we have user enforced (slap on the wrist) policies which make this new feature a burden for us. I do not think the individual user should be able to opt out if that's what you were hinting at. Your feature, for those environments which want to use it, should be on for all users which it is applicable. I completely understand your use case. I'm just asking for a way to opt out of the new functionality for some or all users. I also completely understand the overhead of adding yet another flag which needs to be maintained and validated repeatedly for functionality. Leverage the quiet mode is an extra step and then all the confirmations to be clicked subsequently... followed by removing quiet mode. In summary, not everyone requires or asked for the new feature. We should not all be subjected to it. Jenkins had been around a very long time without it and while there were likely asks, it was not a big enough ask for anyone to actually build it until now. 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-41065) Add permission to require confirmation to cancel job
Title: Message Title Jeff G created an issue Jenkins / JENKINS-41065 Add permission to require confirmation to cancel job Issue Type: Improvement Assignee: Unassigned Components: core Created: 2017/Jan/13 1:07 PM Environment: 2.32.1 on Ubuntu Labels: build-queue Priority: Minor Reporter: Jeff G Recently, core was updated to require confirmation when a running job is attempted to be cancelled or removed from the queue. JENKINS-30565 I would like this to be controlled by a permission. Something along the lines of "requires cancel confirmation". The default value would be to require the confirmation which follows the existing behavior. In our environment, we would not require the administrative group to get this confirmation dialog. Use Case: Several jobs spawned automatically which need to be aborted rapidly. Not all jobs in the queue fall in this category at the time so purging the entire queue (which we have a scriptler to handle) is not appropriate.
[JIRA] [buildgraph-view-plugin] (JENKINS-34803) Update to version 1.3 of build-graph-view plugin crashes Jenkins hard
Title: Message Title Jeff G edited a comment on JENKINS-34803 Re: Update to version 1.3 of build-graph-view plugin crashes Jenkins hard Same issue with my environment.UbuntuJenkins LTS 1.651.1 and 1.651.2 Buildgraph View Plugin 1.3For now I've disabled the plugin. 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] [buildgraph-view-plugin] (JENKINS-34803) Update to version 1.3 of build-graph-view plugin crashes Jenkins hard
Title: Message Title Jeff G commented on JENKINS-34803 Re: Update to version 1.3 of build-graph-view plugin crashes Jenkins hard Same issue with my environment. Ubuntu Jenkins LTS 1.651.1 and 1.651.2 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] [maven-plugin] (JENKINS-34138) jenkins jobs are failing at maven installation
Title: Message Title Jeff G commented on JENKINS-34138 Re: jenkins jobs are failing at maven installation We also just recently started seeing this issue within the last couple of weeks I believe. In my configuration, I am loading all 5 executors with the same job via remote triggering using a curl statement without any delay. This job spawning configuration has not been changed in several months. Recently, however, I have noticed this defect's error turn up and all jobs fail. I am thinking there is contention against the destination maven installation folder. Environment details... Ubuntu Jenkins LTS 1.642.2 (will be 1.642.3 this weekend) Windows 2008 Slave 5 Executors Maven 3.0.4 JDK 8 While my scenario is around concurrently executing a single maven project, I expect any combination of multiple Maven projects could result in this condition. This is unless Jenkins has some built in throttle mechanism which is not being respected while using a single project concurrently. Unfortunately, the Windows slave in my case is effectively dead to Maven projects after this and I need to kill the Java process on the system before it will serve Maven projects again. I agree with the Critical status of this Defect. 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] [maven-plugin] (JENKINS-33388) Concurrent Maven Job Execution reporting alternate build's module status
Title: Message Title Jeff G updated an issue Jenkins / JENKINS-33388 Concurrent Maven Job Execution reporting alternate build's module status Change By: Jeff G For my nightly integration test Jenkins environment, I have a "driver" job which is responsible for spawning about 50 of a "runner" jobs which has set parameters, one per test. This "runner" job is set to run concurrently on two nodes, one with 5 executors and the other with 3 executors.The runner job has the following components worth noting...* Injects environment properties based on . for the job to use to determine its own database* Using a label to distribute runner job to two specific nodes* Mercurial SCM* Triggering builds remotely using an authentication token* Deleting workspace before the build starts* Pre-build Actions** Trigger another project (blocking) - This job sets up the determined schema* Maven Build (default Maven build project step): clean install -U -C -P -pl -D* Post-build Actions** Groovy Postbuild: Setting some build short text** Publish HTML Reports** Editable e-mail notificationThe "runner" jobs can take anywhere from 45 to 75 minutes, depending on what each test is doing and how long the blocking import takes (if it needs to rebuild the schema or just reset + import data).I have noticed that intermittently, but pretty much at least one per night, one execution of the "runner" job will report as unstable even though the console and reports show as successful. Drilling into the *job* console output, it shows as successful. Drilling into the *module* console output, it shows the output of a different execution of the same job (one example being about 10 minutes earlier based on console output time). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [maven-plugin] (JENKINS-33388) Concurrent Maven Job Execution reporting alternate build's module status
Title: Message Title Jeff G updated an issue Jenkins / JENKINS-33388 Concurrent Maven Job Execution reporting alternate build's module status Change By: Jeff G For my nightly integration test Jenkins environment, I have a "driver" job which is responsible for spawning about 50 of a "runner" jobs which has set parameters, one per test. This "runner" job is set to run concurrently on two nodes, one with 5 executors and the other with 3 executors.The runner job has the following components worth noting...* Injects environment properties based on . for the job to use get determine its own database to use * Using a label to distribute runner job to two specific nodes* Mercurial SCM* Triggering builds remotely using an authentication token* Deleting workspace before the build starts* Pre-build Actions** Trigger another project (blocking) - This job sets up my assigned the determined schema* Maven Build (default Maven build project step): clean install -U -C -P -pl -D* Post-build Actions** Groovy Postbuild: Setting some build short text** Publish HTML Reports** Editable e-mail notificationThe "runner" jobs can take anywhere from 45 to 75 minutes, depending on what each test is doing and how long the blocking import takes (if it needs to rebuild the schema or just reset + import data).I have noticed that intermittently, but pretty much at least one per night, one execution of the "runner" job will report as unstable even though the console and reports show as successful. Drilling into the *job* console output, it shows as successful. Drilling into the *module* console output, it shows the output of a different execution of the same job (one example being about 10 minutes earlier based on console output time). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [maven-plugin] (JENKINS-33388) Concurrent Maven Job Execution reporting alternate build's module status
Title: Message Title Jeff G updated an issue Jenkins / JENKINS-33388 Concurrent Maven Job Execution reporting alternate build's module status Change By: Jeff G Summary: Concurrent Maven Job Execution reporting alternate build's module status 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] [maven-plugin] (JENKINS-33388) Concurrent Maven Job Execution reporting alternate build's status
Title: Message Title Jeff G updated an issue Jenkins / JENKINS-33388 Concurrent Maven Job Execution reporting alternate build's status Change By: Jeff G For my nightly integration test Jenkins environment, I have a "driver" job which is responsible for spawning about 50 of a "runner" jobs which has set parameters, one per test. This "runner" job is set to run concurrently on two nodes, one with 5 executors and the other with 3 executors.The runner job has the following components worth noting...* Injects environment properties based on . for the job to use get its own database to use* Using a label to distribute runner job to two specific nodes* Mercurial SCM* Triggering builds remotely using an authentication token* Deleting workspace before the build starts* Pre-build Actions** Trigger another project (blocking) - This job sets up my assigned schema* Maven Build (default Maven build project step): clean install -U -C -P -pl -D* Post-build Actions** Groovy Postbuild: Setting some build short text** Publish HTML Reports** Editable e-mail notificationThe "runner" jobs can take anywhere from 45 to 75 minutes, depending on what each test is doing and how long the blocking import takes (if it needs to rebuild the schema or just reset + import data) .I have noticed that intermittently, but pretty much at least one per night, one execution of the "runner" job will report as unstable even though the console and reports show as successful. Drilling into the *job* console output, it shows as successful. Drilling into the *module* console output, it shows the output of a different execution of the same job (one example being about 10 minutes earlier based on console output time). Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
[JIRA] [maven-plugin] (JENKINS-33388) Concurrent Maven Job Execution reporting alternate build's status
Title: Message Title Jeff G created an issue Jenkins / JENKINS-33388 Concurrent Maven Job Execution reporting alternate build's status Issue Type: Bug Assignee: Unassigned Components: maven-plugin Created: 08/Mar/16 2:01 PM Environment: Jenkins 1.642.2 Master on Ubuntu, Slave on Windows 2008, Maven 3.0.4, All plugins at latest (as of March 2016), JDK 1.8, Labels: maven-plugin Priority: Major Reporter: Jeff G For my nightly integration test Jenkins environment, I have a "driver" job which is responsible for spawning about 50 of a "runner" jobs which has set parameters, one per test. This "runner" job is set to run concurrently on two nodes, one with 5 executors and the other with 3 executors. The runner job has the following components worth noting... Injects environment properties based on . for the job to use get its own
[JIRA] [build-user-vars-plugin] (JENKINS-32532) User build variables are not injected on "Before Build" step
Title: Message Title Jeff G commented on JENKINS-32532 Re: User build variables are not injected on "Before Build" step +1 for having this addressed. Same symptom as above, using the Before Build notification trigger. 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] [build-user-vars-plugin] (JENKINS-25199) Build user variables not supported for Auto triggered jobs
Title: Message Title Jeff G commented on JENKINS-25199 Re: Build user variables not supported for Auto triggered jobs While this would be convenient, I have gotten around this limitation by having an upstream job pass in a BUILD_USER variable as something like "UPSTREAM JOB" so it can be used later. 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] [build-blocker-plugin] (JENKINS-30779) I need a way to configure blocking behavior for different jobs
Title: Message Title Jeff G commented on JENKINS-30779 Re: I need a way to configure blocking behavior for different jobs You might be able to use the Throttle Concurrent Builds plugin to do this. 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] [build-blocker-plugin] (JENKINS-22059) Use parameters in build-blocker Regulary Expression
Title: Message Title Jeff G commented on JENKINS-22059 Re: Use parameters in build-blocker Regulary _expression_ I would also like to see variable (job parameter) resolution added to the plugin. 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] [build-keeper-plugin] (JENKINS-31743) Add Comment as to why build is being marked for keep
Title: Message Title Jeff G created an issue Jenkins / JENKINS-31743 Add Comment as to why build is being marked for keep Issue Type: Improvement Assignee: bap Components: build-keeper-plugin Created: 25/Nov/15 2:36 PM Priority: Minor Reporter: Jeff G It would be nice if you could optionally leave a comment as to why a build was marked to be kept. For example, an intermittent unit test failure which you create a defect for. You might want to keep the build where it occurred and add the defect to it. This way, someone else would not come by and mark it for cleaning thinking it had been forgotten. Add Comment
[JIRA] [parameterized-trigger-plugin] (JENKINS-22600) Sub-projects appeared as "Static" and "Other executed recently" at job main page
Title: Message Title Jeff G commented on JENKINS-22600 Re: Sub-projects appeared as "Static" and "Other executed recently" at job main page I'm using Jenkins 1.609.3 and am also experiencing this problem. Triggering several downstream jobs from a "driver" job. A couple of the downstream jobs are a health check used by several other jobs. As a result, the driver job shows "Other executed recently" of those shared jobs several times. I am not using the conditional build step anywhere in this job. All of my plugins are updated to the latest monthly in my environment. System information. Master OS: Ubuntu Slave OS: Ubuntu/SuSe/Windows 2008 I first observed this around a year ago and just got around to commenting on this ticket. Added to the vote. 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] [other] (JENKINS-2382) Quiet period never expires...
Title: Message Title Jeff G commented on JENKINS-2382 Re: Quiet period never expires... Patric, that is because no change was ever made regarding SCM polling not causing the quiet time to be reset. To avoid your issue, you should have a quiet period which is smaller than the polling. 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] [mercurial-plugin] (JENKINS-27749) Incoming Changeset Message Regex
Jeff G resolved JENKINS-27749 as Fixed Incoming Changeset Message Regex Pull request #64. https://github.com/jenkinsci/mercurial-plugin/pull/64 Change By: Jeff G (07/Apr/15 12:57 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [mercurial-plugin] (JENKINS-27749) Incoming Changeset Message Regex
Jeff G assigned JENKINS-27749 to Jeff G Incoming Changeset Message Regex Change By: Jeff G (06/Apr/15 12:23 AM) Assignee: JesseGlick JeffG This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [mercurial-plugin] (JENKINS-27749) Incoming Changeset Message Regex
Jeff G created JENKINS-27749 Incoming Changeset Message Regex Issue Type: New Feature Assignee: Jesse Glick Components: mercurial-plugin Created: 06/Apr/15 12:23 AM Description: Add a global configuration to the Mercurial SCM section which accepts a regex. This regex will be applied to each new changeset commit message. If the changeset matches, the existing 'hg status' check will be performed between the prior revision and the matching one. If the changeset does not match, the next changeset (if there is one) will be checked. Project: Jenkins Priority: Minor Reporter: Jeff G This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [mercurial-plugin] (JENKINS-25523) Multiple SCMs Plugin doesn't work with Mercurial plugin 1.51
Jeff G commented on JENKINS-25523 Multiple SCMs Plugin doesnt work with Mercurial plugin 1.51 I also confirm this is fixed. I had upgraded to Mercurial 1.53-SNAPSHOT for some local dev work and this issue showed up again. Then I upgraded Multiple SCM plugin from 0.3 to 0.4 and the issue went away again. I think the problem is that the Plugin Manager does not show 0.4 as available, perhaps due to the 1.0 release version? This causes people to come here and report the issue because it does not appear there is an upgrade available for Multiple SCMs when there actually is. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [mercurial-plugin] (JENKINS-26762) notifyCommit should trigger builds with trailing / defined in SCM URL
Jeff G commented on JENKINS-26762 notifyCommit should trigger builds with trailing / defined in SCM URL Thank you for the clarification on the process here Jesse. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [mercurial-plugin] (JENKINS-26762) notifyCommit should trigger builds with trailing / defined in SCM URL
Jeff G commented on JENKINS-26762 notifyCommit should trigger builds with trailing / defined in SCM URL If you are not volunteering to fix it, shouldn't you unassign yourself so someone else can if they so decide? I don't have the bandwidth to do this myself and have already updated the few inconsistent jobs to be consistent. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [claim-plugin] (JENKINS-26976) Sticky Claim on failed build should persist only if build remains failed (not if it becomes unstable)
Jeff G commented on JENKINS-26976 Sticky Claim on failed build should persist only if build remains failed (not if it becomes unstable) I do not agree with this defect. If changed, please make it a (global) configuration point defaulting to the current behavior of remaining stuck if going from fail to unstable or unstable to fail. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [mercurial-plugin] (JENKINS-26762) notifyCommit should trigger builds with trailing / defined in SCM URL
Jeff G commented on JENKINS-26762 notifyCommit should trigger builds with trailing / defined in SCM URL Thanks Jesse. Will this be included in the next scheduled release of the plugin? If so, do you know when that is scheduled to be? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [mercurial-plugin] (JENKINS-26762) notifyCommit should trigger builds with trailing / defined in SCM URL
Jeff G created JENKINS-26762 notifyCommit should trigger builds with trailing / defined in SCM URL Issue Type: Bug Assignee: Jesse Glick Components: mercurial-plugin Created: 03/Feb/15 8:24 PM Description: When the SCM repository URL is configured with a trailing slash, the notifyCommit will not observe the change without it. Example... Mercurial repo is located at http://scm root/fooRepo Jenkins job is defined as http://scm root/fooRepo/ notifyCommit URL call is http://jenkins root/mercurial/notifyCommit?url="" root/fooRepo The above Jenkins Job is not triggered. I can call notifyCommit with the trailing slash and only the above job is triggered, no other jobs which are listening to the same repo without the trailing slash. Due to the large number of job authors on my team, there can be a mix of SCM URL configurations across jobs. I have just begun using the notifyCommit feature and ran across this issue. I think the target should check both URLs ending with or without a trailing slash. Environment: Ubuntu Jenkins 1.580.2 Project: Jenkins Priority: Minor Reporter: Jeff G This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [http_request] (JENKINS-21994) Add HTTP header
Jeff G commented on JENKINS-21994 Add HTTP header I was surprised to see that assigning headers to the request was not already a built in feature to this plugin. This will prevent me from being able to use this plugin. I have not found any other plugins which could run as a build step using headers so I will have to resort to bash with wget. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [nodelabelparameter-plugin] (JENKINS-24280) Environment variables get corrupted when using Node parameter
Jeff G commented on JENKINS-24280 Environment variables get corrupted when using Node parameter It works when I pin it to a single node via the "Restrict where this project can be run" job configuration. It still does not work when using the Node Parameter Plugin for a single node either. Unfortunately, we do not have the resources available to set up a new Jenkins instance to test this. Based on the other comments, this is easy to reproduce for anyone who wants to attempt to fix it. Added information. This is only a problem for my two Windows slave nodes. I have the same configuration for several Linux nodes and it is able to find the 'sh' command without issue. This matches the first comment of this defect. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [nodelabelparameter-plugin] (JENKINS-24280) Environment variables get corrupted when using Node parameter
Jeff G commented on JENKINS-24280 Environment variables get corrupted when using Node parameter Also confirmed on Jenkins 1.580.1 with Env Inject 1.90. I cannot uninstall Env Inject to verify. The work around of running pinned to a node instead of using the Node Parameter plugin does work as expected. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [claim] (JENKINS-23513) Claim plugin doesn't allow you to claim unstable builds.
Jeff G commented on JENKINS-23513 Claim plugin doesnt allow you to claim unstable builds. I would also really like to see this improvement done. In our environment, we have nightly integration tests which run and are flagged as unstable if any of their tests fail. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [throttle-concurrents] (JENKINS-23591) Job Configuration page jumps when Throttle Concurrent Builds is checked
Jeff G created JENKINS-23591 Job Configuration page jumps when Throttle Concurrent Builds is checked Issue Type: Bug Assignee: abayer Components: throttle-concurrents Created: 26/Jun/14 1:18 PM Description: Within a job configuration page, selecting the Throttle Concurrent Builds checkbox causes the page to jump 1-2 pages down, causing the user to have to scroll back up. It would be nice if the page did not jump like this. I am using 1.8.2. Project: Jenkins Labels: plugin jenkins configuration api job Priority: Minor Reporter: Jeff G This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [jobconfighistory] (JENKINS-22644) Build history job config changed link does not respect Jenkins url
Jeff G created JENKINS-22644 Build history job config changed link does not respect Jenkins url Issue Type: Bug Affects Versions: current Assignee: Mirko Friedenhagen Components: jobconfighistory Created: 16/Apr/14 12:51 PM Description: When a job config change is made, the first subsequent build has a wrench icon with link to the job config. This link does not respect the Jenkins URL and instead points directly at hostname/job/currentJobName/jobConfigHistory/showdiff My Jenkins installation is behind hostname/jenkins so the generated link is broken. All other jobConfigHistory links appear to be mapped correctly. Environment: Jenkins 1.552 on Ubuntu with jobConfigHistory plugin version 2.6 installed Project: Jenkins Labels: plugin job Priority: Minor Reporter: Jeff G This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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.
