[JIRA] (JENKINS-61143) Match text fails when called from views
Title: Message Title Stephan Pauxberger created an issue Jenkins / JENKINS-61143 Match text fails when called from views Issue Type: Bug Assignee: Tomas Westling Components: build-failure-analyzer-plugin Created: 2020-02-19 09:48 Priority: Minor Reporter: Stephan Pauxberger This is related to JENKINS-54839. When calling from inside a view in the ui, the view is still part of the url, which fails the "Match text" with an AssertionError. Basically, we could simply extend the replace all string from https://github.com/jenkinsci/build-failure-analyzer-plugin/pull/93/commits/a80fcd073ec50faecf2e088ffd6ad45395fb6d4e, but this would not handle cornercases like a job named view well, so the replacement should be improved a little bit. A will create a PR for that. Add Comment
[JIRA] (JENKINS-47027) "Not valid UTF8" when using umlauts in Failure cause management
Title: Message Title Stephan Pauxberger commented on JENKINS-47027 Re: "Not valid UTF8" when using umlauts in Failure cause management This seems to be a problem in encoding the form values. I solved that by switching to POST, see: https://github.com/jenkinsci/build-failure-analyzer-plugin/pull/109 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.185408.1506001816000.18770.1563884520131%40Atlassian.JIRA.
[JIRA] (JENKINS-22026) Propagate failure causes from downstream builds
Title: Message Title Stephan Pauxberger commented on JENKINS-22026 Re: Propagate failure causes from downstream builds I created a PR (https://github.com/jenkinsci/build-failure-analyzer-plugin/pull/107) which should fix this by using the downstream-build-cache, which does contain that information anyway. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.153803.1393886704000.16239.1563523501060%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-22026) Propagate failure causes from downstream builds
Title: Message Title Stephan Pauxberger edited a comment on JENKINS-22026 Re: Propagate failure causes from downstream builds I created a PR ([https://github.com/jenkinsci/build-failure-analyzer-plugin/pull/107)] which should fix this by using the downstream-build-cache, which does contain that information anyway. I will also work with pipeline jobs. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.153803.1393886704000.16249.1563523504437%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56347) Kubernetes plugin provisioning pods twice in 1.14.6
Title: Message Title Stephan Pauxberger commented on JENKINS-56347 Re: Kubernetes plugin provisioning pods twice in 1.14.6 Same here, downgrading to 1.14.5 solved it for now. Did not yet get around to setting up a test system. 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-56246) VERSION Column on Mysql is too small
Title: Message Title Stephan Pauxberger commented on JENKINS-56246 Re: VERSION Column on Mysql is too small Thanks and sorry for not answering, last weeks were pretty full... 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-56246) VERSION Column on Mysql is too small
Title: Message Title Stephan Pauxberger commented on JENKINS-56246 Re: VERSION Column on Mysql is too small Neither was I, but I got an Exception citing exactly this limit. Therefore a clipped my branch names - with a quick check, however, I was not able to reproduce the issue nor to find the source of the exception. Unfortunately, I did not copy the stacktrace, so it might also have been a plugin, but the message clearly stated that Maven versions must not be longer than 100 characters. I will keep looking. 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-56246) VERSION Column on Mysql is too small
Title: Message Title Stephan Pauxberger commented on JENKINS-56246 Re: VERSION Column on Mysql is too small I am using a MariaDB 10.1.29. However, this should be quite independent of the version. Even with 4 byte UTF characters, a column size of 100 is well within the limit (767 bytes) and would still allow all valid Maven versions. Also, we could even allow bigger versions (afaik the 100 chars is not in the specification, but only a de facto limit) by limiting the index to the first 100 characters (https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-column-prefixes) 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-56246) VERSION Column on Mysql is too small
Title: Message Title Stephan Pauxberger created an issue Jenkins / JENKINS-56246 VERSION Column on Mysql is too small Issue Type: Bug Assignee: Alvaro Lobato Components: pipeline-maven-plugin Created: 2019-02-22 13:03 Priority: Major Reporter: Stephan Pauxberger mysql ddl contains: VERSION varchar(56) NOT NULL, However, per definition, Maven versions can be up to 100 characters long (in hsql, ist VARCHAR(256) btw). Since we encode branch names in our version, we break that 56 character boundry. This column should conform to Maven rules for versions. Add Comment
[JIRA] (JENKINS-55138) Exec Failure: HTTP:0. Message:No response
Title: Message Title
Stephan Pauxberger edited a comment on JENKINS-55138
Re: Exec Failure: HTTP:0. Message:No response
we are encountering this error about 10 times a day which is quite critical, since it also breaks jobs which run for over an hour. As with OP, this occured after updating to 1.13.7. Before the upgrade, we had a lot of memory issues in OpenShift, therefore I would like to prevent having to roll back the version. One more thing that I noticed: Once this happens, it seems to affect more than one job. Also, after that there is always the exception later: {noformat}java.util.concurrent.RejectedExecutionException: Task okhttp3.RealCall$AsyncCall@512db46f rejected from java.util.concurrent.ThreadPoolExecutor@2e02dc25[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 258] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) at okhttp3.Dispatcher.enqueue(Dispatcher.java:130) at okhttp3.RealCall.enqueue(RealCall.java:100) at okhttp3.internal.ws.RealWebSocket.connect(RealWebSocket.java:183) at okhttp3.OkHttpClient.newWebSocket(OkHttpClient.java:436) at io.fabric8.kubernetes.client.dsl.internal.PodOperationsImpl.exec(PodOperationsImpl.java:267) at io.fabric8.kubernetes.client.dsl.internal.PodOperationsImpl.exec(PodOperationsImpl.java:61) at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.doLaunch(ContainerExecDecorator.java:318) at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.launch(ContainerExecDecorator.java:236) at hudson.Launcher$ProcStarter.start(Launcher.java:455){noformat} So obviously, the error seems to not really affect the execution, but leads to the TRhreadPoll ThreadPool bein terminated.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this
[JIRA] (JENKINS-55138) Exec Failure: HTTP:0. Message:No response
Title: Message Title
Stephan Pauxberger edited a comment on JENKINS-55138
Re: Exec Failure: HTTP:0. Message:No response
we are encountering this error about 10 times a day which is quite critical, since it also breaks jobs which run for over an hour. As with OP, this occured after updating to 1.13.7. Before the upgrade, we had a lot of memory issues in OpenShift, therefore I would like to prevent having to roll back the version. One more thing that I noticed: Once this happens, it seems to affect more than one job. Also, after that there is always the exception later: { quote noformat } {{ java.util.concurrent.RejectedExecutionException: Task okhttp3.RealCall$AsyncCall@ 3300fdcc 512db46f rejected from java.util.concurrent.ThreadPoolExecutor@2e02dc25[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 258] }} {{ at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063) }} {{ at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830) }} {{ at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379) }} {{ at okhttp3.Dispatcher.enqueue(Dispatcher.java:130) }} {{ at okhttp3.RealCall.enqueue(RealCall.java:100) }} {{ at okhttp3.internal.ws.RealWebSocket.connect(RealWebSocket.java:183) }} {{ at okhttp3.OkHttpClient.newWebSocket(OkHttpClient.java:436) }} {{ at io.fabric8.kubernetes.client.dsl.internal.PodOperationsImpl.exec(PodOperationsImpl.java:267) }} {{ at io.fabric8.kubernetes.client.dsl.internal.PodOperationsImpl.exec(PodOperationsImpl.java:61) }} {{ at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.doLaunch(ContainerExecDecorator.java:318) }} {{ at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.launch(ContainerExecDecorator.java:236) }} at hudson.Launcher$ProcStarter.start(Launcher.java:455) { quote noformat } So obviously, the error seems to not really affect the execution, but leads to the TRhreadPoll bein terminated.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-55138) Exec Failure: HTTP:0. Message:No response
Title: Message Title
Stephan Pauxberger commented on JENKINS-55138
Re: Exec Failure: HTTP:0. Message:No response
we are encountering this error about 10 times a day which is quite critical, since it also breaks jobs which run for over an hour. As with OP, this occured after updating to 1.13.7. Before the upgrade, we had a lot of memory issues in OpenShift, therefore I would like to prevent having to roll back the version. One more thing that I noticed: Once this happens, it seems to affect more than one job. Also, after that there is always the exception later:
java.util.concurrent.RejectedExecutionException: Task okhttp3.RealCall$AsyncCall@3300fdcc rejected from java.util.concurrent.ThreadPoolExecutor@2e02dc25[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 258] {{ at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)}} {{ at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)}} {{ at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)}} {{ at okhttp3.Dispatcher.enqueue(Dispatcher.java:130)}} {{ at okhttp3.RealCall.enqueue(RealCall.java:100)}} {{ at okhttp3.internal.ws.RealWebSocket.connect(RealWebSocket.java:183)}} {{ at okhttp3.OkHttpClient.newWebSocket(OkHttpClient.java:436)}} {{ at io.fabric8.kubernetes.client.dsl.internal.PodOperationsImpl.exec(PodOperationsImpl.java:267)}} {{ at io.fabric8.kubernetes.client.dsl.internal.PodOperationsImpl.exec(PodOperationsImpl.java:61)}} {{ at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.doLaunch(ContainerExecDecorator.java:318)}} {{ at org.csanchez.jenkins.plugins.kubernetes.pipeline.ContainerExecDecorator$1.launch(ContainerExecDecorator.java:236)}}
So obviously, the error seems to not really affect the execution, but leads to the TRhreadPoll bein terminated.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-55138) Exec Failure: HTTP:0. Message:No response
Title: Message Title Stephan Pauxberger updated an issue Jenkins / JENKINS-55138 Exec Failure: HTTP:0. Message:No response Change By: Stephan Pauxberger Priority: Minor Major 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-51073) local repo does not work maven wrapper
Title: Message Title Stephan Pauxberger commented on JENKINS-51073 Re: local repo does not work maven wrapper I created a minimal pull request for this: https://github.com/jenkinsci/pipeline-maven-plugin/pull/147 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-51073) local repo does not work maven wrapper
Title: Message Title Stephan Pauxberger created an issue Jenkins / JENKINS-51073 local repo does not work maven wrapper Issue Type: Bug Assignee: Alvaro Lobato Components: pipeline-maven-plugin Created: 2018-05-02 11:02 Priority: Major Reporter: Stephan Pauxberger currently, the entry for the local repo is created like this: -Dmaven.repo.local="/any/repo" which works when using maven directly, because the quotes get sorted out in the original mvn script. However, when using the maven wrapper, this script is bypassed, the property is passed to the maven-wrapper as is, leading to the local repository being created in /local-dir/"/any/repo" which means there is a directory named " in the path. Which is clearly not expected here. While the problem is a really bad chaining of escaping and quoting and should ultimately by fixed in Maven itself to correctly handle this setup, an easy solution would be to wrap the whole property definition in quotes, i.e. "-Dmaven.repo.local=/any/repo" Add Comment
[JIRA] [delivery-pipeline-plugin] (JENKINS-28055) Pipeline arrows are not displaying or displayed incorrectly
Title: Message Title Stephan Pauxberger commented on JENKINS-28055 Re: Pipeline arrows are not displaying or displayed incorrectly Downgrade to JQuery Plugin 1.7.2-1 seems to solve both problems (wrong arrows and JS errors) 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] [job-dsl-plugin] (JENKINS-28458) Deleting views when the containing folder has already been deleted leads to NPE
Title: Message Title Stephan Pauxberger created an issue Jenkins / JENKINS-28458 Deleting views when the containing folder has already been deleted leads to NPE Issue Type: Bug Assignee: Daniel Spilker Components: job-dsl-plugin Created: 18/May/15 4:00 PM Priority: Minor Reporter: Stephan Pauxberger Simple case of missing NPE guard: Create a dsl that creates a folder a view in that folder run the dsl now remove the folder and the view rerun the job NPE occurs
[JIRA] [delivery-pipeline-plugin] (JENKINS-27270) Support jobs organized under folders
Stephan Pauxberger resolved JENKINS-27270 as Fixed Support jobs organized under folders Merged (should be in 0.8.11) Change By: Stephan Pauxberger (23/Mar/15 8:46 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] [delivery-pipeline-plugin] (JENKINS-27539) NPE when using jobs with the same name in different folders
Stephan Pauxberger resolved JENKINS-27539 as Fixed NPE when using jobs with the same name in different folders Merged (should be in 0.8.11) Change By: Stephan Pauxberger (23/Mar/15 8:46 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] [delivery-pipeline-plugin] (JENKINS-27270) Support jobs organized under folders
Stephan Pauxberger commented on JENKINS-27270 Support jobs organized under folders Pull Request: https://github.com/Diabol/delivery-pipeline-plugin/pull/98 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] [delivery-pipeline-plugin] (JENKINS-27539) NPE when using jobs with the same name in different folders
Stephan Pauxberger commented on JENKINS-27539 NPE when using jobs with the same name in different folders Pull Request: https://github.com/Diabol/delivery-pipeline-plugin/pull/98 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] [delivery-pipeline-plugin] (JENKINS-27539) NPE when using jobs with the same name in different folders
Stephan Pauxberger created JENKINS-27539 NPE when using jobs with the same name in different folders Issue Type: Bug Assignee: Patrik Boström Components: delivery-pipeline-plugin Created: 22/Mar/15 4:27 PM Description: When using the same basic item name for more than one job in different folders, and those items are used in a pipeline, the view is not displayed (Error communicating to server! Server Error) The stacktrace shows an NPE: Caused by: java.lang.NullPointerException at org.jgrapht.graph.AbstractGraph.assertVertexExist(Unknown Source) at org.jgrapht.graph.AbstractBaseGraph$DirectedSpecifics.getEdgeContainer(Unknown Source) at org.jgrapht.graph.AbstractBaseGraph$DirectedSpecifics.outDegreeOf(Unknown Source) at org.jgrapht.graph.AbstractBaseGraph.outDegreeOf(Unknown Source) at se.diabol.jenkins.pipeline.domain.Stage.findAllRunnablePaths(Stage.java:267) at se.diabol.jenkins.pipeline.domain.Stage.placeStages(Stage.java:225) at se.diabol.jenkins.pipeline.domain.Stage.extractStages(Stage.java:164) at se.diabol.jenkins.pipeline.domain.Pipeline.extractPipeline(Pipeline.java:123) at se.diabol.jenkins.pipeline.DeliveryPipelineView.getComponent(DeliveryPipelineView.java:323) at se.diabol.jenkins.pipeline.DeliveryPipelineView.getPipelines(DeliveryPipelineView.java:293) ... 90 more The reason is that ProjectUtil.getAllDownstreamProjects() stores the projects in a map using the simple name as a key. So of all equally named projects only one is retained, so the firstProject is usually not found as vertex in the graph leading to the NPE. I will create a Pull Request for that. Environment: 0.8.10 Project: Jenkins Priority: Major Reporter: Stephan Pauxberger 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] [git-client-plugin] (JENKINS-25444) CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not
Stephan Pauxberger
created JENKINS-25444
CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not
Issue Type:
Bug
Assignee:
Nicolas De Loof
Components:
git-client-plugin
Created:
05/Nov/14 10:19 AM
Description:
Git plugin calls fetch with branch always with deleteBranchIfExists, which in case of CliGit results in the call of
launchCommand("checkout", "-f", ref);
which in turn throws away all local modifications and leaves a clean status.
JGit, however simply (re)sets the reference of refs/heads/branch and does a normal checkout, which leaves changes open.
Project:
Jenkins
Priority:
Major
Reporter:
Stephan Pauxberger
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] [git-client-plugin] (JENKINS-25444) CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not
Stephan Pauxberger
updated JENKINS-25444
CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not
Change By:
Stephan Pauxberger
(05/Nov/14 11:14 AM)
Description:
GitplugincallsfetchwithbranchalwayswithdeleteBranchIfExists,whichincaseofCliGitresultsinthecallof{code}launchCommand(checkout,-f,ref);{code}whichinturnthrowsawayalllocalmodificationsandleavesacleanstatus.
in
JGit,
howeversimply
setForce
(
re
)
setsthereferenceofrefs/heads/branchand
isalsoused,but
does
anormalcheckout
notseemtoworkasexpected.Therearealreadycommentsinthecodediscussingthisbehviour
,
whichleaveschangesopen
buttheyonlypointtocheckoutconflicts
.
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] [git-client-plugin] (JENKINS-25444) CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not
Stephan Pauxberger commented on JENKINS-25444 CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not Created pull request 153 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] [git-client-plugin] (JENKINS-25444) CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not
Stephan Pauxberger commented on JENKINS-25444 CliGit implementation of fetch/deleteBranch does remove open changes, JGit does not Just for the sake of completeness: JGit.CheckoutCommand.setForce() is not equivalent to CLI "checkout -f" but "checkout -B", i.e. to force the resetting of a branch. 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] [maven-plugin] (JENKINS-21597) New Maven Plugin causes slowdown for huge multimodule projects
Stephan Pauxberger commented on JENKINS-21597 New Maven Plugin causes slowdown for huge multimodule projects The actual slowdown was due to a bug in a plugin of mine. Still, some plugins like gerrit-trigger or build-failure-analyzer now behave differently. For example, bfa prints whole screens full of messages for each module. Basically, all plugins using RunListener can be effected. Problem is, they not simply exclude MavenBuild s from being handled, because that would introduce unwanted dependencies to maven-plugin. 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] [core] (JENKINS-25406) Some post step build result in IllegalStateException
Stephan Pauxberger created JENKINS-25406 Some post step build result in IllegalStateException Issue Type: Bug Assignee: Sonar Team Components: core, sonar, violations-plugin Created: 02/Nov/14 9:57 PM Description: This one seems to be rather tricky. After upgrade to 1.587, I saw this exception during the the run of the sonar plugin in a post step: 20:19:33 Warte bis Jenkins die Datensammlung abgeschlossen hat 20:19:33 [ERROR] Internal error: java.lang.IllegalStateException: cannot change build result while in COMPLETED - [Help 1] 20:19:33 org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalStateException: cannot change build result while in COMPLETED 20:19:33 at org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) 20:19:33 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) 20:19:33 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) 20:19:33 at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) 20:19:33 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) 20:19:33 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) 20:19:33 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) 20:19:33 at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:117) 20:19:33 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 20:19:33 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 20:19:33 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 20:19:33 at java.lang.reflect.Method.invoke(Method.java:597) 20:19:33 at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) 20:19:33 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) 20:19:33 at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:178) 20:19:33 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 20:19:33 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 20:19:33 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 20:19:33 at java.lang.reflect.Method.invoke(Method.java:597) 20:19:33 at hudson.maven.Maven3Builder.call(Maven3Builder.java:136) 20:19:33 at hudson.maven.Maven3Builder.call(Maven3Builder.java:71) 20:19:33 at hudson.remoting.UserRequest.perform(UserRequest.java:121) 20:19:33 at hudson.remoting.UserRequest.perform(UserRequest.java:49) 20:19:33 at hudson.remoting.Request$2.run(Request.java:324) 20:19:33 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 20:19:33 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 20:19:33 at java.util.concurrent.FutureTask.run(FutureTask.java:138) 20:19:33 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) 20:19:33 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) 20:19:33 at java.lang.Thread.run(Thread.java:662) 20:19:33 Caused by: java.lang.IllegalStateException: cannot change build result while in COMPLETED 20:19:33 at hudson.model.Run.setResult(Run.java:458) 20:19:33 at hudson.maven.MavenBuild$ProxyImpl.setResult(MavenBuild.java:494) 20:19:33 at hudson.maven.MavenBuild$ProxyImpl2.setResult(MavenBuild.java:547) 20:19:33 at sun.reflect.GeneratedMethodAccessor318.invoke(Unknown Source) 20:19:33 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 20:19:33 at java.lang.reflect.Method.invoke(Method.java:483) 20:19:33 at hudson.model.Executor$1.call(Executor.java:579) 20:19:33 at hudson.util.InterceptingProxy$1.invoke(InterceptingProxy.java:23) 20:19:33 at com.sun.proxy.$Proxy91.setResult(Unknown Source) 20:19:33 at sun.reflect.GeneratedMethodAccessor318.invoke(Unknown Source)
[JIRA] [core] (JENKINS-25406) Some post step build result in IllegalStateException
Stephan Pauxberger updated JENKINS-25406 Some post step build result in IllegalStateException Change By: Stephan Pauxberger (02/Nov/14 9:57 PM) Priority: Minor Critical 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] [git-client-plugin] (JENKINS-25387) JGit implentation of Git Client Plugin should also support
Stephan Pauxberger created JENKINS-25387 JGit implentation of Git Client Plugin should also support Issue Type: New Feature Assignee: Nicolas De Loof Components: git-client-plugin Created: 31/Oct/14 1:47 AM Description: Right now, the JGit implementation does not support reference repositories, because the clone and init commands do not support it directly. However, by using the repository builder directly, alternate directories can be set. I will provide a pull request for this. Project: Jenkins Priority: Major Reporter: Stephan Pauxberger 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] [git-client-plugin] (JENKINS-25387) JGit implentation of Git Client Plugin should also support
Stephan Pauxberger edited a comment on JENKINS-25387 JGit implentation of Git Client Plugin should also support Created pull request 151 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] [git-client-plugin] (JENKINS-25387) JGit implentation of Git Client Plugin should also support
Stephan Pauxberger commented on JENKINS-25387 JGit implentation of Git Client Plugin should also support Create pull request 151 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] [job-dsl-plugin] (JENKINS-23318) GerritContext does not honor default settings in Jenkins' Gerrit Trigger config
Stephan Pauxberger updated JENKINS-23318 GerritContext does not honor default settings in Jenkins Gerrit Trigger config Change By: Stephan Pauxberger (05/Jun/14 9:00 AM) Description: InJenkinsGerritTriggerPlugindefaultconfiguration,youcansetdefaultvaluesforvariousbuildresults(likesuccessful:V1,failed:V-1).Thesescanbeoverridenbyspecificjobconfigurations.However,GerritContextalwaysoverridesthesevaluesusingdefaultvalueshardwiredintheclass.Icreatedapullrequestchangingtheclassappropiatelyby introducinganew usingnullas defaultvalue (UNDEFINED-MIN_INT) ,thecorrespondingnodesonlygetwrittenintotheconfiguration,whenanexplicitvaluehasbeenset. 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.
