[JIRA] (JENKINS-53926) Builds hang ocassionally on resume after Jenkins restart
Title: Message Title
Marcin Zajączkowski created an issue
Jenkins / JENKINS-53926
Builds hang ocassionally on resume after Jenkins restart
Issue Type:
Bug
Assignee:
Carlos Sanchez
Components:
kubernetes-plugin
Created:
2018-10-05 16:46
Environment:
Jenkins 2.138.1, Kubernetes plugin 1.12.6, Kubernetes 1.11
Priority:
Minor
Reporter:
Marcin Zajączkowski
Occasionally, we observe an issue with resuming jobs after a Jenkins Master restart. Our configuration. Jenkins 2.138.1 (some older versions had the same problem) with the init.groovy.d configuration + persistent jobs running on top of the Kubernetes cluster. Slaves/executors are setup with the Kubernetes plugin 1.12.6 on Kubernetes 1.11. After the Jenkins master restart a simple job (a git clone + a shell script) sometimes resume properly:
15:19:18 Commit message: "Quick commit"
15:19:18 > git rev-list --no-walk aa9bd4a093e0364df0f52f5447c15f3785f0 # timeout=10
[Pipeline] }
[Pipeline] // dir
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Execute my fancy shell script)
[Pipeline] sh
Resuming build at Wed Oct 01 13:19:59 GMT 2018 after Jenkins restart
Waiting to resume part of x-x #40: ‘jenkins-slave-x-x-x-x’ is offline
15:19:19 [x-x] Running shell script
15:19:22 + vault login '-method=aws' 'role=jenkins'
Waiting to resume part of x-x #40: ‘jenkins-slave-x-x-x-x’ is offline
Waiting to resume part of x-x #40: ‘jenkins-slave-x-x-x-x’ is offline
Waiting to resume part of x-x #40
Ready to run at Wed Oct 01 13:20:13 GMT 2018
15:20:13 A
[JIRA] (JENKINS-50435) Unable to abort build executing Groovy Postbuild script
Title: Message Title
Marcin Zajączkowski created an issue
Jenkins / JENKINS-50435
Unable to abort build executing Groovy Postbuild script
Issue Type:
Bug
Assignee:
Daniel Heid
Components:
postbuildscript-plugin
Created:
2018-03-27 14:22
Environment:
Jenkins 2.60, Groovy Postbuild 2.3.1
Priority:
Minor
Reporter:
Marcin Zajączkowski
It seems to be problematic to abort a build executing a Groovy Postbuild script using the Jenkins UI and even internal Jenkins API. I tried to check if the current thread isn't interupted (Thread.currentThread().isInterrupted()), but it's not. The build results (manager.getResult()) is also SUCCESS. Sample code:
int i=0
while (true) {
if (++i > 20) { //to do not create a zombie build :)
manager.listener.logger.println "Timeout. Aborting..."
break
}
if (Thread.currentThread().isInterrupted()) {
manager.listener.logger.println "Interrupted. Aborting..."
break
}
manager.listener.logger.println "Not aborted - ${manager.getResult()} - ${Thread.currentThread().isInterrupted()}"
sleep(1000)
}
results in:
Not aborted - SUCCESS - false
Not aborted - SUCCESS - false
(...)
Not aborted - SUCCESS - false
Timeout. Aborting...
[JIRA] (JENKINS-23251) BUILD_USER_ID is not set when the build is fired using the API
Title: Message Title Marcin Zajączkowski commented on JENKINS-23251 Re: BUILD_USER_ID is not set when the build is fired using the API Should be fixed by https://github.com/jenkinsci/build-user-vars-plugin/pull/13 . However, a build cause doesn't know about triggering user when a token is used and only "remoteTrigger" dummy username is set. 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-25199) Build user variables not supported for Auto triggered jobs
Title: Message Title Marcin Zajączkowski commented on JENKINS-25199 Re: Build user variables not supported for Auto triggered jobs Should be fixed by https://github.com/jenkinsci/build-user-vars-plugin/pull/13 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-43090) Set BUILD_USER_ID for anonymous user
Title: Message Title Marcin Zajączkowski commented on JENKINS-43090 Re: Set BUILD_USER_ID for anonymous user Should be fixed by https://github.com/jenkinsci/build-user-vars-plugin/pull/13 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-29253) Please set BUILD_USER to 'timer' for scheduled jobs
Title: Message Title Marcin Zajączkowski commented on JENKINS-29253 Re: Please set BUILD_USER to 'timer' for scheduled jobs Fix provided in https://github.com/jenkinsci/build-user-vars-plugin/pull/13 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-29253) Please set BUILD_USER to 'timer' for scheduled jobs
Title: Message Title Marcin Zajączkowski assigned an issue to Marcin Zajączkowski Jenkins / JENKINS-29253 Please set BUILD_USER to 'timer' for scheduled jobs Change By: Marcin Zajączkowski Assignee: Marcin Zajączkowski 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-43090) Set BUILD_USER_ID for anonymous user
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-43090 Set BUILD_USER_ID for anonymous user Issue Type: Improvement Assignee: Marcin Zajączkowski Components: build-user-vars-plugin Created: 2017/Mar/24 2:41 PM Environment: 1.5 Priority: Minor Reporter: Marcin Zajączkowski For anonymous user BUILD_USER is set, but BUILD_USER_ID is not. It's problematic in places which use BUILD_USER_ID. ID should be set to "anonymous" which is a reserved username in Jenkins. Add Comment
[JIRA] (JENKINS-42960) Case insensitive search in fixed sets doesn't work in some cases
Title: Message Title Marcin Zajączkowski started work on JENKINS-42960 Change By: Marcin Zajączkowski Status: Open In Progress 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-42960) Case insensitive search in fixed sets doesn't work in some cases
Title: Message Title Marcin Zajączkowski commented on JENKINS-42960 Re: Case insensitive search in fixed sets doesn't work in some cases Will be fixed in https://github.com/jenkinsci/jenkins/pull/2801. 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-42960) Case insensitive search in fixed sets doesn't work in some cases
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-42960 Case insensitive search in fixed sets doesn't work in some cases Issue Type: Bug Assignee: Marcin Zajączkowski Components: core Created: 2017/Mar/21 10:47 AM Environment: Jenkins 2.50 Priority: Minor Reporter: Marcin Zajączkowski Case insensitive search in fixed sets doesn't work due to wrong comparison in code if the result to filter needs to be lower cased. Add Comment
[JIRA] (JENKINS-42645) Search in Jenkins should be case insensitive by default
Title: Message Title Marcin Zajączkowski started work on JENKINS-42645 Change By: Marcin Zajączkowski Status: Reopened In Progress 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-40718) Search by build param values in Build history widget
Title: Message Title Marcin Zajączkowski closed an issue as Done Jenkins / JENKINS-40718 Search by build param values in Build history widget Change By: Marcin Zajączkowski Status: Resolved Closed 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-40718) Search by build param values in Build history widget
Title: Message Title Marcin Zajączkowski reopened an issue Jenkins / JENKINS-40718 Search by build param values in Build history widget Change By: Marcin Zajączkowski Resolution: Fixed Status: Resolved Reopened 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-40718) Search by build param values in Build history widget
Title: Message Title Marcin Zajączkowski resolved as Fixed Available in 2.50. Jenkins / JENKINS-40718 Search by build param values in Build history widget Change By: Marcin Zajączkowski Status: In Progress Resolved Resolution: Fixed 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-40718) Search by build param values in Build history widget
Title: Message Title Marcin Zajączkowski resolved as Done Jenkins / JENKINS-40718 Search by build param values in Build history widget Change By: Marcin Zajączkowski Status: Reopened Resolved Resolution: Done 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-42645) Search in Jenkins should be case insensitive by default
Title: Message Title Marcin Zajączkowski reopened an issue Wrong issue... Should be JENKINS-40718. Jenkins / JENKINS-42645 Search in Jenkins should be case insensitive by default Change By: Marcin Zajączkowski Resolution: Done Status: Closed Reopened 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
[JIRA] (JENKINS-42645) Search in Jenkins should be case insensitive by default
Title: Message Title Marcin Zajączkowski updated an issue Jenkins / JENKINS-42645 Search in Jenkins should be case insensitive by default Change By: Marcin Zajączkowski Environment: Jenkikns Jenkins 2.49 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-42645) Search in Jenkins should be case insensitive by default
Title: Message Title Marcin Zajączkowski closed an issue as Done Jenkins / JENKINS-42645 Search in Jenkins should be case insensitive by default Change By: Marcin Zajączkowski Status: Resolved Closed 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-42645) Search in Jenkins should be case insensitive by default
Title: Message Title Marcin Zajączkowski resolved as Done Available in 2.50. Jenkins / JENKINS-42645 Search in Jenkins should be case insensitive by default Change By: Marcin Zajączkowski Status: Open Resolved Resolution: Done 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-42709) Unable to build Jenkins with Java 8 set as target version
Title: Message Title Marcin Zajączkowski commented on JENKINS-42709 Re: Unable to build Jenkins with Java 8 set as target version Baptiste Mathus Feel free to take it. I'm currently working on some other PRs and will not come back to that Java 8 related very soon. 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-42709) Unable to build Jenkins with Java 8 set as target version
Title: Message Title
Marcin Zajączkowski updated an issue
Jenkins / JENKINS-42709
Unable to build Jenkins with Java 8 set as target version
Change By:
Marcin Zajączkowski
Playing with some Java 8 related improvements in Jenkins I've noticed that Jenkins cannot be built with Java 8 set as desired source/target level and it looks somehow tricky.{code:java}[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ jenkins-core ---[INFO] Changes detected - recompiling the module![INFO] Compiling 1048 source files to /home/foo/Code/jenkins/core/target/classes[INFO] -[ERROR] COMPILATION ERROR :[INFO] -[ERROR] /home/foo/Code/jenkins/core/src/main/java/hudson/model/User.java:[658,22] error: method fromJobs in class RunList cannot be applied to given types;[ERROR] required: Iterable found: Iterable reason: inferred type does not conform to lower bound(s) inferred: J#2 lower bound(s): T,Job where J#1,R#1,R#2,J#2,R#3,T are type-variables: J#1 extends Job declared in method fromJobs(Iterable) R#1 extends Run declared in method fromJobs(Iterable) R#2 extends Run declared in class RunList J#2 extends Job R#3 extends Run T extends J#2/home/foo/Code/jenkins/core/src/main/java/hudson/model/Computer.java:[781,22] error: method fromJobs in class RunList cannot be applied to given types;[INFO] 2 errors[INFO] -[INFO] [INFO] Reactor Summary:[INFO][INFO] Jenkins main module SUCCESS [ 2.169 s][INFO] Jenkins cli SUCCESS [ 3.655 s][INFO] Jenkins core ... FAILURE [ 35.684 s][INFO] Jenkins war SKIPPED[INFO] Tests for Jenkins core . SKIPPED[INFO] [INFO] BUILD FAILURE{code} Error can be reproduced in my [branch|https://github.com/szpak/jenkins/tree/tech/JENKINS-42709-unableToBuildForJava8]. As migration to Java 8 is getting closer and closer it would be good to have it solved.
[JIRA] (JENKINS-42709) Unable to build Jenkins with Java 8 set as target version
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-42709 Unable to build Jenkins with Java 8 set as target version Issue Type: Bug Assignee: Unassigned Components: core Created: 2017/Mar/13 9:39 AM Environment: Jenkins 2.49, master as of 2017-03-12 Priority: Minor Reporter: Marcin Zajączkowski Playing with some Java 8 related improvements in Jenkins I've noticed that Jenkins cannot be built with Java 8 set as desired source/target level and it looks somehow tricky. [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ jenkins-core --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 1048 source files to /home/foo/Code/jenkins/core/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /home/foo/Code/jenkins/core/src/main/java/hudson/model/User.java:[658,22] error: method fromJobs in class RunList cannot be applied to given types; [ERROR] required: Iterableextends J#1> found: Iterable reason: inferred type does not conform to lower bound(s) inferred: J#2 lower bound(s): T,Job where J#1,R#1,R#2,J#2,R#3,T are type-variables: J#1 extends Job declared in method fromJobs(Iterableextends J#1>) R#1 extends Run declared in method fromJobs(Iterableextends J#1>) R#2 extends Run declared in class RunList J#2 extends Job R#3 extends Run T extends J#2 /home/foo/Code/jenkins/core/src/main/java/hudson/model/Computer.java:[781,22] error: method fromJobs in class RunList cannot b
[JIRA] (JENKINS-42701) Search should be case insensitive by default also for existing users
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-42701 Search should be case insensitive by default also for existing users Issue Type: Improvement Assignee: Unassigned Components: core Created: 2017/Mar/12 11:27 PM Environment: Jenkins 2.50 Priority: Minor Reporter: Marcin Zajączkowski As explained in JENKINS-42645 it would be good to have case insensitive search by default also for existing users (especially after search in builds has been "case insensitive search" user property aware - JENKINS-40718). Unfortunately it would be hard to determine if that property is set for historical reasons or user opt-in to case sensitive search intentionally. One of the possible ways is to switch all users to case sensitive search and create another "stronger" property to get know about that. In the future the old property could be removed. Unfortunately it is quite ugly solution and I hope that someone will propose something better. Add Comment
[JIRA] (JENKINS-42645) Search in Jenkins should be case insensitive by default
Title: Message Title Marcin Zajączkowski commented on JENKINS-42645 Re: Search in Jenkins should be case insensitive by default Related PR: https://github.com/jenkinsci/jenkins/pull/2801 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-42645) Search in Jenkins should be case insensitive by default
Title: Message Title
Marcin Zajączkowski updated an issue
Jenkins / JENKINS-42645
Search in Jenkins should be case insensitive by default
Change By:
Marcin Zajączkowski
As [discussed|https://groups.google.com/d/topic/jenkinsci-dev/I9PVV3j0Eb8/discussion] on the mailing list [1] there seems to be consensus that case insensitive search in Jenkins is much more intuitive. This unfortunately is an opposite to the situation [available|https://github.com/jenkinsci/jenkins/blob/76b5ba7f4641102917d551764e275f3d6044186e/core/src/main/java/hudson/search/UserSearchProperty.java#L28-L29] in Jenkins as of this issue creation [2]. In a context of [changes|https://github.com/jenkinsci/jenkins/pull/2683#issuecomment-275952138] in JENKINS-40718 (and the same approach in other places) it would be no longer possible to find FAILED jobs just by typing "fail" ("FAIL" would be required). This is counterproductive and misleading.This issue assumes change the default behavior for newly crated users and for an anonymous user.In addition it would be good to consider (probably as a separate issue to do not postpone the main action ) a possibility to change that behavior for users that haven't intentionally opt-in to have case sensitive search. Unfortunately it can be impossible to determine that situation. Therefore maybe it would be beneficial (to prevent a "regression" related to JENKINS-40718 and similar changes) to reset that behavior and require from an user to opt-in to it once more - however, it could be somehow clumsy in the implementation (e.g. two values in XML for the same feature). Suggestions for that are welcome.
Add Comment
[JIRA] (JENKINS-42645) Search in Jenkins should be case insensitive by default
Title: Message Title
Marcin Zajączkowski created an issue
Jenkins / JENKINS-42645
Search in Jenkins should be case insensitive by default
Issue Type:
Improvement
Assignee:
Marcin Zajączkowski
Components:
core
Created:
2017/Mar/09 10:13 PM
Environment:
Jenkikns 2.49
Priority:
Minor
Reporter:
Marcin Zajączkowski
As discussed on the mailing list [1] there seems to be consensus that case insensitive search in Jenkins is much more intuitive. This unfortunately is an opposite to the situation available in Jenkins as of this issue creation [2]. In a context of changes in JENKINS-40718 (and the same approach in other places) it would be no longer possible to find FAILED jobs just by typing "fail" ("FAIL" would be required). This is counterproductive and misleading. This issue assumes change the default behavior for newly crated users and for an anonymous user. In addition it would be good to consider (probably as a separate issue) a possibility to change that behavior for users that haven't intentionally opt-in to have case sensitive search. Unfortunately it can be impossible to determine that situation. Therefore maybe it would be beneficial (to prevent a "regression" related to JENKINS-40718 and similar changes) to reset that behavior and require from an user to opt-in to it once more - however, it could be somehow clumsy in the implementation (e.g. two values in XML for the same feature). Suggestions for that are welcome.
[JIRA] (JENKINS-40718) Search by build param values in Build history widget
Title: Message Title Marcin Zajączkowski commented on JENKINS-40718 Re: Search by build param values in Build history widget Corresponding PR: https://github.com/jenkinsci/jenkins/pull/2683 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-40718) Search by build param values in Build history widget
Title: Message Title Marcin Zajączkowski assigned an issue to Unassigned Jenkins / JENKINS-40718 Search by build param values in Build history widget Change By: Marcin Zajączkowski Assignee: R. Tyler Croy 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-40718) Search by build param values in Build history widget
Title: Message Title Marcin Zajączkowski moved an issue Jenkins / JENKINS-40718 Search by build param values in Build history widget Change By: Marcin Zajączkowski Project: Infrastructure Jenkins Key: INFRA JENKINS - 1023 40718 Workflow: classic default workflow JNJira + In-Review Component/s: core Component/s: core Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this mess
[JIRA] (JENKINS-37138) Performance regression due to symbol annotations
Title: Message Title Marcin Zajączkowski commented on JENKINS-37138 Re: Performance regression due to symbol annotations Link to the discussion: https://groups.google.com/forum/#!topic/job-dsl-plugin/3QCC-T2hr-Y 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-37138) Performance regression due to symbol annotations
Title: Message Title Marcin Zajączkowski updated an issue Jenkins / JENKINS-37138 Performance regression due to symbol annotations Change By: Marcin Zajączkowski URL: https://groups.google.com/forum/#!topic/job-dsl-plugin/3QCC-T2hr-Y 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-37138) Performance regression due to symbol annotations
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-37138 Performance regression due to symbol annotations Issue Type: Bug Assignee: Daniel Spilker Components: job-dsl-plugin Created: 2016/Aug/03 8:31 AM Environment: Job DSL 1.46+ Jenkins 2.2+ Priority: Major Reporter: Marcin Zajączkowski After migration to Jenkins 2.11 (from 1.642.4) some time ago we noticed a significant performance regression in the execution time of our Job DSL seeds. For example a time of generation ~3500 jobs in one seed doubled (from ~7 minutes to ~15). I analyzed the problem and after digging it out, profiling and bisecting the code I was able to find a reason. The "regression" was introduced in Jenkins 2.2 and affects only Jenkins 2.2+ and Job DSL 1.46+. Job DSL 1.46 started to use @Symbol to use `SymbolLookup` from Structs plugin to find `DescribableModel`s (in a `DescribableHelper` class). In general symbols are good, but also seems to be much slower. This is especially painful in a seed which creates dozens/hundreds of the same pipelines for different µservices/products/realms (for example based on custom configuration descriptors resolved in a Git repo) - the same lookup operations are repeated. I have some ideas how it could be improved/mitigated and I will start a discussion on the project mailing list.
[JIRA] (JENKINS-36825) NoStaplerConstructorException with Jenkins 2.x+
Title: Message Title Marcin Zajączkowski closed an issue as Not A Defect Jenkins / JENKINS-36825 NoStaplerConstructorException with Jenkins 2.x+ Change By: Marcin Zajączkowski Status: Open Closed Resolution: Not A Defect 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-36825) NoStaplerConstructorException with Jenkins 2.x+
Title: Message Title Marcin Zajączkowski commented on JENKINS-36825 Re: NoStaplerConstructorException with Jenkins 2.x+ Seems to be a regression fixed in Jenkins 2.12. Tested with 2.14 and works fine. Closing this 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-36825) NoStaplerConstructorException with Jenkins 2.x+
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-36825 NoStaplerConstructorException with Jenkins 2.x+ Issue Type: Bug Assignee: samngms Components: filesystem_scm-plugin Created: 2016/Jul/20 3:05 PM Environment: filesystem_scm-plugin 1.20 Jenkins 2.9+ Priority: Major Reporter: Marcin Zajączkowski The plugin (1.20) is broken with Jenkins 2.9+. NoStaplerConstructorException: There's no @DataBoundConstructor on any constructor of class hudson.plugins.filesystem_scm.FSSCM on saving configuration. In fact in code the annotation is commented out. Add Comment
[JIRA] [delivery-pipeline-plugin] (JENKINS-35507) Paging not usable with large number of historical builds
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-35507 Paging not usable with large number of historical builds Issue Type: Bug Assignee: Patrik Boström Attachments: pipeline-view-with-paging.png, pipeline-view-without-paging.png Components: delivery-pipeline-plugin Created: 2016/Jun/09 4:12 PM Environment: Jenkins 1.642.3, delivery-pipeline-plugin 0.9.11 Priority: Critical Reporter: Marcin Zajączkowski It seems that paging mechanism ( JENKINS-28918 ) introduced regression in the situation where the first job in the pipeline has many historical builds. With paging enabled `Pipeline.createPipelineLatest()` creates a `Pipeline` instance for [every](https://github.com/Diabol/delivery-pipeline-plugin/commit/072343839463fe97a5b09e3ac47ef9f9433b239b#diff-abd99f83e18e7913a8ea3929339bc3a2R228) historical build (even if just a few will be displayed in the pipeli
[JIRA] [delivery-pipeline-plugin] (JENKINS-34196) Delivery pipeline API returns all jobs in JSON response makes Jenkins unusable
Title: Message Title Marcin Zajączkowski commented on JENKINS-34196 Re: Delivery pipeline API returns all jobs in JSON response makes Jenkins unusable Related discussion on the mailing list (with no response from the project maintainers so far) - https://groups.google.com/forum/#!topic/delivery-pipeline-plugin/PruzPC2-9Ck 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] [disk-usage-plugin] (JENKINS-33219) Job.updateNextBuildNumber can cause deadlock
Title: Message Title Marcin Zajączkowski commented on JENKINS-33219 Re: Job.updateNextBuildNumber can cause deadlock I've had similar situation and have thread dump with information of acquired locks (attached). disk-usage-plugin thread so some "computation" in synchronized section (...) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at jenkins.model.lazy.LazyBuildMixIn.loadBuild(LazyBuildMixIn.java:156) at jenkins.model.lazy.LazyBuildMixIn$1.create(LazyBuildMixIn.java:133) at hudson.model.RunMap.retrieve(RunMap.java:223) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:479) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:461) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:367) - locked <0x0005f57899b0> (a hudson.model.RunMap) at hudson.model.RunMap.getById(RunMap.java:204) at hudson.model.RunMap.getById(RunMap.java:56) (...) while other requests are blocked on synchronized section: "Handling GET / from 192.168.72.4 : RequestHandlerThread[#1110] View/index.jelly Dashboard/main.jelly LatestBuilds/portlet.jelly LatestBuilds/latestbuilds.jelly" #1979423 daemon prio=5 os_prio=0 tid=0x7f84b0008000 nid=0x147de waiting for monitor entry [0x7f85728f1000] java.lang.Thread.State: BLOCKED (on object monitor) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:356) I don't see a classic deadlock there. My suspicion is rather that the reason (in additional to newly added synchronized block to fix JENKINS-22767 ) was large number of historical builds (7K+). It could just take some time for disk-usage-plugin to calculate required data (which the other several request threads for that project just was waiting to the first one to finish). However I'm not sure if it is related only to disk-usage-plugin. After its removal (and restart) I observed the same situation with the thread handling side panel request (below). I'm not sure why sidepanel.jelly should also take much time in that place. "Handling GET /job/somejob-pr/ from 9.9.9.9 : RequestHandlerThread[#15] Job/index.jelly AbstractProject/sidepanel.jelly HistoryWidget/index.jelly" #97 daemon prio=5 os_prio=0 tid=0x7f8104008800 nid=0x15ad2 runnable [0x7f81e28e] java.lang.Thread.State: RUNNABLE at java.lang.Object.hashCode(Native Method) at java.util.HashMap.hash(HashMap.java:338) at java.util.HashMap.get(HashMap.java:556) at com.thoughtworks.xstream.mapper.DefaultImplementationsMapper.defaultImplementationOf(DefaultImplementationsMapper.java:69) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultI
[JIRA] [disk-usage-plugin] (JENKINS-33219) Job.updateNextBuildNumber can cause deadlock
Title: Message Title
Marcin Zajączkowski edited a comment on JENKINS-33219
Re: Job.updateNextBuildNumber can cause deadlock
I've had similar situation (Jenkins 1.642.3) and have thread dump with information of acquired locks (attached).disk-usage-plugin thread so some "computation" in synchronized section{code}(...) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at jenkins.model.lazy.LazyBuildMixIn.loadBuild(LazyBuildMixIn.java:156) at jenkins.model.lazy.LazyBuildMixIn$1.create(LazyBuildMixIn.java:133) at hudson.model.RunMap.retrieve(RunMap.java:223) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:479) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:461) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:367) - locked <0x0005f57899b0> (a hudson.model.RunMap) at hudson.model.RunMap.getById(RunMap.java:204) at hudson.model.RunMap.getById(RunMap.java:56)(...){code}while other requests are blocked on synchronized section:{code}"Handling GET / from 192.168.72.4 : RequestHandlerThread[#1110] View/index.jelly Dashboard/main.jelly LatestBuilds/portlet.jelly LatestBuilds/latestbuilds.jelly" #1979423 daemon prio=5 os_prio=0 tid=0x7f84b0008000 nid=0x147de waiting for monitor entry [0x7f85728f1000] java.lang.Thread.State: BLOCKED (on object monitor) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:356){code}I don't see a classic deadlock there. My suspicion is rather that the reason (in additional to newly added synchronized block to fix JENKINS-22767) was large number of historical builds (7K+). It could just take some time for disk-usage-plugin to calculate required data (which the other several request threads for that project just was waiting to the first one to finish).However I'm not sure if it is related only to disk-usage-plugin. After its removal (and restart) I observed the same situation with the thread handling side panel request (below). I'm not sure why sidepanel.jelly should also take much time in that place.{code}"Handling GET /job/somejob-pr/ from 9.9.9.9 : RequestHandlerThread[#15] Job/index.jelly AbstractProject/sidepanel.jelly HistoryWidget/index.jelly" #97 daemon prio=5 os_prio=0 tid=0x7f8104008800 nid=0x15ad2 runnable [0x7f81e28e] java.lang.Thread.State: RUNNABLE at java.lang.Object.hashCode(Native Method) at java.util.HashMap.hash(HashMap.java:338) at java.util.HashMap.get(HashMap.java:556) at com.thoughtworks.xstream.mapper.DefaultImplementationsMapper.defaultImplementationOf(DefaultImplementationsMapper.java:69) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.AnnotationMapper.defaultImplementationOf(AnnotationMapper.java:143) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at com.thoughtworks.xstream.mapper.AnnotationMapper.defaultImplementationOf(AnnotationMapper.java:143) at hudson.util.xstream.MapperDelegate.defaultImplementationOf(MapperDelegate.java:59) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementati
[JIRA] [disk-usage-plugin] (JENKINS-33219) Job.updateNextBuildNumber can cause deadlock
Title: Message Title Marcin Zajączkowski updated an issue Jenkins / JENKINS-33219 Job.updateNextBuildNumber can cause deadlock Thread dump Change By: Marcin Zajączkowski Attachment: jstack-thread-dump-blocked-AbstractLazyLoadRunMap-JENKINS-33219.txt 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] [rundeck-plugin] (JENKINS-34510) Very long Jenkins startup time with a vast number of Rundeck jobs
Title: Message Title Marcin Zajączkowski commented on JENKINS-34510 Re: Very long Jenkins startup time with a vast number of Rundeck jobs Promised PR: https://github.com/jenkinsci/rundeck-plugin/pull/24 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] [rundeck-plugin] (JENKINS-34510) Very long Jenkins startup time with a vast number of Rundeck jobs
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-34510 Very long Jenkins startup time with a vast number of Rundeck jobs Issue Type: Bug Assignee: Vincent Behar Components: rundeck-plugin Created: 2016/Apr/29 1:21 PM Environment: Jenkins 1.642.3 rundeck-plugin 3.5.2 Priority: Major Reporter: Marcin Zajączkowski Having Jenkins instance with a vast number of rundeck jobs Jenkins startup time increases dramatically. With 1500+ rundeck jobs on very strong AWS instance Jenkins starts up over 30 minutes. That number of jobs can be easy to achieve having automatically generated (e.g. with Jenkins JobDSL) deployment pipelines for multiple products deployed in multiple countries. After the analyze it turned out that rundeck-plugin makes a hit to Rundeck about job details for every runcked job in Jenkins (in RundeckJobProjectLinkerAction to display details on a build page). It can take some time, especially if Rundeck is configured to use H2 DB. In many cases number of distinct jobs in Rundeck is very limited (e.g. several) - they are prameterized. Having it cached reduce number all calls dramatically. In our case for 1500+ rundeck jobs (several distinct rundeck jobs) the startup time was reduced from over 30 minutes to less than 30 seconds .
[JIRA] [support-core-plugin] (JENKINS-34269) Suspected deadlock in SupportLogHandler.publish
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-34269 Suspected deadlock in SupportLogHandler.publish Issue Type: Bug Assignee: Steven Christou Components: support-core-plugin Created: 2016/Apr/15 8:46 AM Environment: Jenkins 1.642.3, support-core-plugin 2.31 Priority: Critical Reporter: Marcin Zajączkowski We encountered a situation when 80+ threads were blocked on a lock acquired in SupportLogHandler.publish making the Jenkins instance irresponsible. Most of the threads go through the Pipeline Delivery plugin (which is heavily used by our users), but in the end everything tries to use Jenkins.getItem(java.lang.String). This is not the same as already fixed JENKINS-32622 . Analyzing thread dump I don't see a classic deadlock - all SupportLogHandler calls hang in the same place. Unfortunately the stack trace I have was taken with -F switch and does not have additional information about locks - like who owns the lock. The support-core plugin had been installed a few hours before the accident which happened twice separated by a restart and disappeared after the plugin was removed. I can sen
[JIRA] [envinject-plugin] (JENKINS-30042) EnvInject doesn't see GIT_COMMIT even after SCM phase
Title: Message Title Marcin Zajączkowski commented on JENKINS-30042 Re: EnvInject doesn't see GIT_COMMIT even after SCM phase I ended up with dumping Git commit to file in a shell build step and inject it in the next step using EnvInject (but it could work out-of-box). 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] [envinject-plugin] (JENKINS-30042) EnvInject doesn't see GIT_COMMIT even after SCM phase
Title: Message Title Marcin Zajączkowski commented on JENKINS-30042 Re: EnvInject doesn't see GIT_COMMIT even after SCM phase Manuel Jesús Recena Soto I don't know. It was the new feature and I haven't changed it with the previous version. If it is important to find a reason I could give it a try. 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] [rundeck-plugin] (JENKINS-30214) Run Rundeck as a regular build step
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-30214 Run Rundeck as a regular build step Issue Type: Bug Assignee: Vincent Behar Components: rundeck-plugin Created: 30/Aug/15 4:49 PM Priority: Minor Reporter: Marcin Zajączkowski In some cases (like running a deployment of two dependent applications) it would be useful to be able to call Rundeck as a regular build step. Build steps have a limitation that after the failure of the first one the second is run as well. Add Comment
[JIRA] [rundeck-plugin] (JENKINS-29395) Jenkins doesn't trigger rundeck when failing
Title: Message Title Marcin Zajączkowski edited a comment on JENKINS-29395 Re: Jenkins doesn't trigger rundeck when failing Haven't tried, but AFAIR https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin had an ability to run other (post-)build steps depending on the current build status. You can give it a try. 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] [rundeck-plugin] (JENKINS-29395) Jenkins doesn't trigger rundeck when failing
Title: Message Title Marcin Zajączkowski commented on JENKINS-29395 Re: Jenkins doesn't trigger rundeck when failing Haven't tried, but AFAIR https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin had an ability to run other (post-)build steps depending on the current build 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] [envinject-plugin] (JENKINS-30042) EnvInject doesn't see GIT_COMMIT even after SCM phase
Title: Message Title Marcin Zajączkowski commented on JENKINS-30042 Re: EnvInject doesn't see GIT_COMMIT even after SCM phase May be related to JENKINS-29349. 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] [envinject-plugin] (JENKINS-30042) EnvInject doesn't see GIT_COMMIT even after SCM phase
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-30042 EnvInject doesn't see GIT_COMMIT even after SCM phase Issue Type: Bug Assignee: Manuel Jesús Recena Soto Components: envinject-plugin Created: 19/Aug/15 4:30 PM Environment: Jenkins 1.596.2 Environment Injector Plugin 1.92 GIT plugin 2.4.0 Priority: Minor Reporter: Marcin Zajączkowski Variables provided by Git plugin (tested with GIT_COMMIT) are not accessible in EnvInject plugin even if applied after SCM phase (Build Environment -> Inject environment variables to the build process). Sample Groovy code used in "Evaluated Groovy script": [GIT_COMMIT_SHORT: GIT_COMMIT] ends with: "[EnvInject] - [ERROR] - Problems occurs on injecting env vars as a build wrap: null". It works wine with JOB_NAME or similar. GIT_COMMIT variable is later accessible in a build step. Sample Use case: Get a short version of Git commit SHA fetch by a job.
[JIRA] [git-parameter-plugin] (JENKINS-28597) GIT Parameter Plugin not using stored credentials
Title: Message Title Marcin Zajączkowski commented on JENKINS-28597 Re: GIT Parameter Plugin not using stored credentials I have the same problem. In Jenkins logs there is: Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress http://my-stash/scm/foo/bar.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: Authentication failed at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324) at net.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition.generateContents(GitParameterDefinition.java:314) at net.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition$DescriptorImpl.doFillValueItems(GitParameterDefinition.java:536) ... 70 more 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] [delivery-pipeline-plugin] (JENKINS-28918) Ability to browse previous pipeline with paging
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-28918 Ability to browse previous pipeline with paging Issue Type: New Feature Assignee: Patrik Boström Components: delivery-pipeline-plugin Created: 16/Jun/15 9:39 AM Priority: Minor Reporter: Marcin Zajączkowski It would sometimes useful to be able to browse old pipelines. Displaying 50 pipelines brings some load time issues and it would be good to have an ability to use paging (e.g. 5 pipelines on a page and paging to see more). Add Comment
[JIRA] [stash-pullrequest-builder-plugin] (JENKINS-28831) Global Stash configuration + Jenkins credentials
Title: Message Title Marcin Zajączkowski commented on JENKINS-28831 Re: Global Stash configuration + Jenkins credentials Thanks for info. I've missed issues on GitHub. 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] [stash-pullrequest-builder-plugin] (JENKINS-28831) Global Stash configuration + Jenkins credentials
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-28831 Global Stash configuration + Jenkins credentials Issue Type: Improvement Assignee: nathan m Components: stash-pullrequest-builder-plugin Created: 10/Jun/15 9:38 AM Priority: Major Reporter: Marcin Zajączkowski Currently Stash password is kept as plain text in a job configuration. In addition having a few projects with PRs to build introduces duplication. It would be useful to be able to (optionally?) configure a Stash instance globally in Jenkins and in addition to keep password/credentials encrypted. Add Comment
[JIRA] [rundeck-plugin] (JENKINS-28697) Aborted job is marked as SUCCESS if "Wait for Rundeck" is used
Title: Message Title Marcin Zajączkowski commented on JENKINS-28697 Re: Aborted job is marked as SUCCESS if "Wait for Rundeck" is used Created corresponding PR: https://github.com/jenkinsci/rundeck-plugin/pull/16 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] [rundeck-plugin] (JENKINS-28778) Make delay between polling (for Rundeck job to finish) configurable per job
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-28778 Make delay between polling (for Rundeck job to finish) configurable per job Issue Type: Improvement Assignee: Vincent Behar Components: rundeck-plugin Created: 05/Jun/15 8:51 PM Priority: Minor Reporter: Marcin Zajączkowski Currently the plugin checks if Rundeck job finished every 5 seconds. For short-lasting jobs it can artificially increase the whole build. It would be useful to (optionally) be able to configure a delay for given job. Add Comment
[JIRA] [delivery-pipeline-plugin] (JENKINS-28777) Ability to get SCM changes to display from selected job (not the first)
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-28777 Ability to get SCM changes to display from selected job (not the first) Issue Type: Improvement Assignee: Patrik Boström Components: delivery-pipeline-plugin Created: 05/Jun/15 8:45 PM Priority: Minor Reporter: Marcin Zajączkowski I like an ability to display SCM changes for the newest pipeline, but in one of my pipelines the first job clones CMS content to make a Git tag. The real SCM changes are contained in the second job which clones the main application(s) sources (and use CMS tag from the previous step to make a build). In that case it would be useful to be able to (optionally) select SCM changes from which job should be used to display it in the pipeline view. Add Comment
[JIRA] [delivery-pipeline-plugin] (JENKINS-28708) Add abort button
Title: Message Title Marcin Zajączkowski created an issue Jenkins / JENKINS-28708 Add abort button Issue Type: New Feature Assignee: Patrik Boström Components: delivery-pipeline-plugin Created: 03/Jun/15 8:33 AM Priority: Minor Reporter: Marcin Zajączkowski I like very much the addition of a retry button for a job in a pipeline view. It would be useful to have also an abort button to be able to stop selected job. Add Comment This message was sen
[JIRA] [rundeck-plugin] (JENKINS-28697) Aborted job is marked as SUCCESS if "Wait for Rundeck" is used
Title: Message Title
Marcin Zajączkowski created an issue
Jenkins / JENKINS-28697
Aborted job is marked as SUCCESS if "Wait for Rundeck" is used
Issue Type:
Bug
Assignee:
Vincent Behar
Components:
rundeck-plugin
Created:
02/Jun/15 4:24 PM
Environment:
Rundeck plugin 3.4
Priority:
Major
Reporter:
Marcin Zajączkowski
Looking at the code (RundeckNotifier) if "sleep(5000)" is interupted ("Oops, interrupted !" is in a log) the while loop is finished and current Rundeck job execution status is RUNNING. It causes that switch..case hits "default" and the whole job is marked as SUCESS.
Add Comment
[JIRA] [groovy] (JENKINS-18349) Allow to use @Grab in a Script Console
Marcin Zajączkowski created JENKINS-18349 Allow to use @Grab in a Script Console Issue Type: Bug Affects Versions: current Assignee: vjuranek Components: groovy Created: 14/Jun/13 10:24 AM Description: Currently @Grab works only in Groovy scripts run on a forked JVM. In a Script Console and System Groovy Scripts it ends with: FATAL: org/apache/ivy/core/report/ResolveReport java.lang.NoClassDefFoundError: org/apache/ivy/core/report/ResolveReport It is sometimes useful to be able to extend script abilities with external libs (like HTTP Builder). Project: Jenkins Priority: Minor Reporter: Marcin Zajączkowski 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/groups/opt_out.
[JIRA] [core] (JENKINS-18276) Archiving artifacts from a slave node is extremely slow even with 1.509.1+
Marcin Zajączkowski created JENKINS-18276 Archiving artifacts from a slave node is extremely slow even with 1.509.1+ Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 10/Jun/13 4:27 PM Description: I see no changes in a speed of archiving artifacts after upgrade to 1.515 (with slave upgraded to 2.23) which should have applied fix from JENKINS-7813. 43MB WAR archives in 102 seconds vs. <2 seconds with SCP. No one confirmed on the mailing list that was able to get significant change after upgrade. It was suggested to open the new issue. Environment: Jenkins 1.515, CentOS 6 64-bit, Java 7 (Oracle) Project: Jenkins Priority: Major Reporter: Marcin Zajączkowski 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/groups/opt_out.
[JIRA] [build-flow] (JENKINS-16254) Unable to use Build Name Setter Plugin
Marcin Zajączkowski commented on JENKINS-16254 Unable to use Build Name Setter Plugin Nice trick, thanks. I completely forgot this is just a Build object which can be modified programatically. 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/groups/opt_out.
[JIRA] [build-flow] (JENKINS-16254) Unable to use Build Name Setter Plugin
Marcin Zajączkowski commented on JENKINS-16254 Unable to use Build Name Setter Plugin Other plugins configurable in a "Build Environment" section are also affected. 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/groups/opt_out.
[JIRA] [core] (JENKINS-7813) Archiving artifacts very slow
emszpak reopened JENKINS-7813 Archiving artifacts very slow I see no changes after upgrade to 1.515 (with slave upgraded to 2.23). 43MB WAR archives in 102 seconds vs. <2 seconds with SCP. No one confirmed on the mailing list that was able to get significant change after upgrade. Change By: emszpak (05/Jun/13 1:47 PM) Resolution: Fixed Status: Resolved Reopened 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/groups/opt_out.
[JIRA] [gradle] (JENKINS-17719) Setting GRADLE_USER_HOME per workspace breaks using gradle.properties from user's home
emszpak created JENKINS-17719 Setting GRADLE_USER_HOME per workspace breaks using gradle.properties from user's home Issue Type: Bug Assignee: Gregory Boissinot Components: gradle Created: 23/Apr/13 3:21 PM Description: Setting GRADLE_USER_HOME to a directory inside workspace doesn't allow to read values from gradle.properties (like a password for Sonar). I understand that GRADLE_USER_HOME in a workspace is a good idea, but there could be also a way to read values from user's gradle.properties file (but no clue how to force Gradle to do this - as a workaround some hacks in Jenkins are required). Project: Jenkins Priority: Minor Reporter: emszpak 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/groups/opt_out.
[JIRA] (JENKINS-16260) Job description isn't shown for Build Flow jobs
emszpak created JENKINS-16260 Job description isn't shown for Build Flow jobs Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: build-flow Created: 04/Jan/13 5:50 PM Description: Job description isn't shown for Build Flow jobs on a job dashboard. Environment: Jenkins 1.480.1, Build Flow 0.6 Project: Jenkins Priority: Minor Reporter: emszpak 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
[JIRA] (JENKINS-16254) Unable to use Build Name Setter Plugin
emszpak created JENKINS-16254 Unable to use Build Name Setter Plugin Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: build-flow Created: 03/Jan/13 4:00 PM Description: It is very useful to be able to set a build name for parametrized builds using Build Name Setter Plugin. In a build flow job type there is no "Build Environment" section. Similar situation with Description Setter Plugin. Environment: build-flow-plugin 0.6, Jenkins 1.480.1 Project: Jenkins Priority: Major Reporter: emszpak 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
[JIRA] (JENKINS-12418) flexible publish - Parametrized trigger does not work
emszpak commented on JENKINS-12418 flexible publish - Parametrized trigger does not work @cjo9900, from the comments I thought that fixing issue is waiting for merge of pull request 17 in parameterized-trigger-plugin, but when I asked there the reply was that it rather seems to be already fixed here. How does it really look like? 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
[JIRA] (JENKINS-14475) Conditional build steps should be available as post-build actions
emszpak commented on JENKINS-14475 Conditional build steps should be available as post-build actions owenmehegan: where you able to successfully chain plugins (Flexible Publish -> Conditional Build Step -> Parameterized Trigger)? I was not able to choose "Conditional Build Step" as an action for "Flexible Publish". Maybe you were able to workaround it in some other way? 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
