[JIRA] (JENKINS-54249) GitHub Commit Status Setter - Cannot retrieve Git metadata
Title: Message Title Julien Carsique commented on JENKINS-54249 Re: GitHub Commit Status Setter - Cannot retrieve Git metadata Baptiste Gaillard Thank you! However, this ticket is missing a stack trace for accuracy. The PR you submitted does not match our current install while we do have the same/similar issue. As I wrote in the PR thread: we're encountering the same issue symptom with lower plugin versions (see https://jira.nuxeo.com/browse/NXBT-2867). Our current versions are: CloudBees Jenkins Enterprise 2.164.3.2-rolling Git client plugin 2.7.6 Git plugin 3.9.3 SCM API Plugin 2.4.0 What is your stacktrace and reproduction case please? Is it the same? java.io.IOException: Cannot retrieve Git metadata for the build at org.jenkinsci.plugins.github.util.BuildDataHelper.getCommitSHA1(BuildDataHelper.java:87) at org.jenkinsci.plugins.github.status.sources.BuildDataRevisionShaSource.get(BuildDataRevisionShaSource.java:32) at org.jenkinsci.plugins.github.status.GitHubCommitStatusSetter.perform(GitHubCommitStatusSetter.java:135) Caused: org.jenkinsci.plugins.github.common.CombineErrorHandler$ErrorHandlingException at org.jenkinsci.plugins.github.common.CombineErrorHandler.handle(CombineErrorHandler.java:74) at org.jenkinsci.plugins.github.status.GitHubCommitStatusSetter.perform(GitHubCommitStatusSetter.java:164) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:80) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:67) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) when running step([$class: 'GitHubCommitStatusSetter', reposSource: [$class: 'ManuallyEnteredRepositorySource', url: repos_url], contextSource: [$class: 'ManuallyEnteredCommitContextSource', context: '...'], statusResultSource: [$class: 'ConditionalStatusResultSource', results: [[$class: 'AnyBuildResult', message: status_msg.get(status), state: status)
[JIRA] (JENKINS-39482) GitHub commit status not working with GitHubCommitStatusSetter on first build of branch in multi-branch pipeline
Title: Message Title Julien Carsique commented on JENKINS-39482 Re: GitHub commit status not working with GitHubCommitStatusSetter on first build of branch in multi-branch pipeline Please read docs for pipeline plugin. On first run there is no information about git (pipeline doesn't provide it) Hello Kirill Merkushev , I don't understand your sentence, nor why you closed the ticket as won't fix. This is a major issue. In many cases, the branch will only be built once. I understand that it's a Pipeline / SCM plugin issue at root, maybe already fixed. See for instance https://issues.jenkins-ci.org/browse/JENKINS-41795 So, won't the current issue require a fix to follow the API changes? Thanks Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41591) The Rebuild Last shortcut is missing for Pipeline jobs
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-41591 The Rebuild Last shortcut is missing for Pipeline jobs Issue Type: Bug Assignee: ragesh_nair Components: pipeline, rebuild-plugin Created: 2017/Jan/31 10:26 AM Environment: Jenkins 1.642.4.2 Rebuilder 1.25 Priority: Minor Reporter: Julien Carsique On the job view, the "Rebuild Last" shortcut to "/lastCompletedBuild/rebuild" is missing for the Pipeline jobs. Add Comment
[JIRA] (JENKINS-26133) Shell script taking/returning output/status
Title: Message Title Julien Carsique commented on JENKINS-26133 Re: Shell script taking/returning output/status Fixed in pipeline (workflow-durable-task-step-plugin) 2.4 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-26133) Shell script taking/returning output/status
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-26133 Shell script taking/returning output/status Change By: Julien Carsique Component/s: workflow-durable-task-step-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36951) Deploy artifacts to Maven repository from slave
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-36951 Deploy artifacts to Maven repository from slave Issue Type: New Feature Assignee: Unassigned Components: maven-plugin Created: 2016/Jul/26 12:35 PM Environment: Jenkins ver. 1.642.4.2 Maven Integration plugin 2.13 Priority: Minor Reporter: Julien Carsique The build step 'Deploy artifacts to Maven repository' (RedeployPublisher) feature performs the deployments from the master. That can lead to an UnknownHostException if only the slave can access the target repository. org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to retrieve remote metadata /maven-metadata.xml: Could not transfer metadata /maven-metadata.xml from/to : unknown error at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:143) at hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:193) at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:176) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:723) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1047) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:668) at hudson.model.Run.execute(Run.java:1763) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531) at
[JIRA] (JENKINS-36184) Batch task console is empty
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-36184 Batch task console is empty Issue Type: Bug Assignee: Kohsuke Kawaguchi Attachments: config.xml Components: batch-task-plugin Created: 2016/Jun/23 10:32 AM Environment: Jenkins ver. 1.642.4.2 Batch Task Plugin 1.18 Priority: Blocker Reporter: Julien Carsique The console is empty. See the attached reproduction job: Freestyle, execute a Shell build step which echo "Build Shell OK", then a batch task "test-NXBT-1134" which should echo "Batch task OK". The batch task is supposed to have been executed but it failed for an unknown reason and there is no console. Making the batch task being automatically or manually executed changes nothing to the current issue. Add Comment
[JIRA] [batch-task-plugin] (JENKINS-35188) Invoke Batch Tasks should support Folder absolute path
Title: Message Title Julien Carsique commented on JENKINS-35188 Re: Invoke Batch Tasks should support Folder absolute path +1 for https://github.com/jenkinsci/batch-task-plugin/pull/3 as an improvement regarding the current situation, although keeping the current issue opened. 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] [batch-task-plugin] (JENKINS-35188) Invoke Batch Tasks should support Folder absolute path
Title: Message Title
Julien Carsique edited a comment on JENKINS-35188
Re: Invoke Batch Tasks should support Folder absolute path
Note also that from {{aFolder/aJob}}, the relative reference {{aFolder/aJob}} is wrong and the true relative reference {{aJob}} should work. Else how could it be possible to copy a folder?Finally, the only working reference is the only one which should not :/ In any place, it should be possible to use either absolute or relative path.- /aFolder/aJob should work from anywhere- aJob should work from any job in /aFolder/- aFolder/aJob should not work from /aFolder/ but only from root.
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] [batch-task-plugin] (JENKINS-35188) Invoke Batch Tasks should support Folder absolute path
Title: Message Title Julien Carsique commented on JENKINS-35188 Re: Invoke Batch Tasks should support Folder absolute path Note also that from aFolder/aJob, the relative reference aFolder/aJob is wrong and the true relative reference aJob should work. Else how could it be possible to copy a folder? Finally, the only working reference is the only one which should not :/ 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] [batch-task-plugin] (JENKINS-35188) Invoke Batch Tasks should support Folder relative path
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-35188 Invoke Batch Tasks should support Folder relative path Change By: Julien Carsique Summary: Invoke Batch Tasks must should support Folders Folder relative path 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] [batch-task-plugin] (JENKINS-35188) Invoke Batch Tasks should support Folder absolute path
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-35188 Invoke Batch Tasks should support Folder absolute path Change By: Julien Carsique Summary: Invoke Batch Tasks should support Folder relative absolute path 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] [batch-task-plugin] (JENKINS-35188) Invoke Batch Tasks must support Folders
Title: Message Title Julien Carsique commented on JENKINS-35188 Re: Invoke Batch Tasks must support Folders Félix Belzunce Arcos Indeed, the Full project name is "aFolder/aJob" but: the absolute reference "/aFolder/aJob" is valid too, the configuration screen validates the user entry: both absolute and relative references are accepted. I'm editing the issue title to be more precise: beside that bug, the folders are supported, you're right. However, I confirm there is an issue: the configuration screen validates a value which is later not working. The bug is likely not in the validation but in the later use. The screens must be consistent and I don't see any reason to restrict the use to relative paths only, is there? 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] [cloudbees-folder-plugin] (JENKINS-35158) Searchbox must support Folders
Title: Message Title Julien Carsique commented on JENKINS-35158 Re: Searchbox must support Folders Depending on how much time is required to properly fix that feature, it could be relevant to first add a post filtering as a workaround: displaying invalid URLs is confusing and, moreover, the redirect to 404 in case of exact match is a bigger issue: users complain that the job is missing or that the URL is broken... 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] [batch-task-plugin] (JENKINS-35188) Invoke Batch Tasks must support Folders
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-35188 Invoke Batch Tasks must support Folders Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: batch-task-plugin, cloudbees-folder-plugin Created: 2016/May/27 4:19 PM Environment: Jenkins 1.642.2 Folders Plugin 5.11 Batch Task Plugin 1.17 Priority: Minor Reporter: Julien Carsique When using folders (plugin), the batch tasks to be triggered must be referenced with an absolute path: while the task suggestion field works fine with a relative job path during configuration, the batch task is not properly configured in the later screens. Let's consider a folder named aFolder with a job named aJob; that job has a batch task named aBatchTask On http://.../jenkins/job/aFolder/job/aJob/configure : Add an Invoke batch tasks post build step with two tasks, one absolute and one relative: Project: /aFolder/aJob Task: aBatchTask
[JIRA] [cloudbees-folder-plugin] (JENKINS-35158) Searchbox must support Folders
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-35158 Searchbox must support Folders Change By: Julien Carsique Environment: Jenkins 1.642.2Folders Plugin 5.11 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] [cloudbees-folder-plugin] (JENKINS-35158) Searchbox must support Folders
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-35158 Searchbox must support Folders Change By: Julien Carsique Component/s: cloudbees-folder-plugin Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-35158) Searchbox must support Folders
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-35158 Searchbox must support Folders Issue Type: Bug Assignee: Unassigned Attachments: Pasted image at 2016_05_25 18_08.png Components: core Created: 2016/May/26 5:15 PM Priority: Major Reporter: Julien Carsique When using folders (plugin), the search returns two results for a unique job: one with the job name and one with the folder plus the job name. The second one works fine, not the first one. When the searched phrase exactly matches a job name, you are redirected to that job instead of getting a list of results. As a consequence, searching for a job contained in a folder by its exact name will lead to a 404 page. For instance, in the attached screenshot, searching for "addons_nuxeo-drive-server-7.10" which is contained in the "7.10" folder: hitting enter lead to 404 waiting for the suggested results returns an unusable "addons_nuxeo-drive-server-7.10" and a working "7.10
[JIRA] [batch-task-plugin] (JENKINS-33833) Lost the batch task history since 1.634
Title: Message Title Julien Carsique commented on JENKINS-33833 Re: Lost the batch task history since 1.634 This issue makes the batch tasks hard to use: while the task is not executing, you don't see the waiting build and cannot know if the build request worked. Daniel Beck, please link it with JENKINS-26445 if you think it's related. Why do you think so? Or maybe are you talking about one of it's subtasks or a side effect? JENKINS-26445 resolution dates and versions do not match. Did you mean that JENKINS-30899 introduced the regression? 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] [batch-task-plugin] (JENKINS-33833) Lost the batch task history since 1.634
Title: Message Title Julien Carsique edited a comment on JENKINS-33833 Re: Lost the batch task history since 1.634 This issue makes the batch tasks hard to use: while the task is not executing, you don't see the waiting build and cannot know if the build request worked or even happened .[~danielbeck], please link it with JENKINS-26445 if you think it's related. Why do you think so? Or maybe are you talking about one of it's subtasks or a side effect? JENKINS-26445 resolution dates and versions do not match. Did you mean that JENKINS-30899 introduced the regression? 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] [batch-task-plugin] (JENKINS-33833) Lost the batch task history since 1.634
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-33833 Lost the batch task history since 1.634 Change By: Julien Carsique Priority: Minor Major 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] [jira-plugin] (JENKINS-33293) (Jira) Updater throws NullPointerException for labels
Title: Message Title Julien Carsique commented on JENKINS-33293 Re: (Jira) Updater throws NullPointerException for labels There are two separate issues: NPE on labels is blocker for the comments. Fixed with https://github.com/jenkinsci/jira-plugin/pull/92 null labels come from somewhere; I couldn't quickly figure how. What are the labels? JIRA labels? Why would you hard-code it to master? The above fix simply initiates the labels as an empty list when the constructor is called with a null value, and it works fine as a preventive action without any unwanted behavior (see for instance https://jira.nuxeo.com/browse/NXP-18806 which has been properly updated by the jira plugin with that fix). I suggest to solve the current issue with such a fix https://github.com/jenkinsci/jira-plugin/pull/92. Then, create a dedicated issue for the labels if something does not work as expected. 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] [jira-plugin] (JENKINS-33551) NPE Error updating JIRA issues
Title: Message Title Julien Carsique commented on JENKINS-33551 Re: NPE Error updating JIRA issues Updated the PR with JENKINS-33293 ref 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] [jira-plugin] (JENKINS-33551) NPE Error updating JIRA issues
Title: Message Title Julien Carsique resolved as Duplicate Jenkins / JENKINS-33551 NPE Error updating JIRA issues Change By: Julien Carsique Status: Open Resolved Resolution: Duplicate 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] [jira-plugin] (JENKINS-33293) (Jira) Updater throws NullPointerException for labels
Title: Message Title Julien Carsique edited a comment on JENKINS-33293 Re: (Jira) Updater throws NullPointerException for labels There are maybe two separate issues:- NPE on labels is blocker for the comments. Fixed with https://github.com/jenkinsci/jira-plugin/pull/92- null labels come from somewhere; I couldn't quickly figure how. What are the labels? JIRA labels? Why would you hard-code it to master? The above fix simply initiates the labels as an empty list when the constructor is called with a null value, and it works fine as a preventive action without any unwanted behavior (see for instance https://jira.nuxeo.com/browse/NXP-18806 which has been properly updated by the jira plugin with that fix). I suggest to solve the current issue with such a fix https://github.com/jenkinsci/jira-plugin/pull/92. Then, create a dedicated issue for the labels if something does not work as expected. 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] [jira-plugin] (JENKINS-33551) NPE Error updating JIRA issues
Title: Message Title Julien Carsique commented on JENKINS-33551 Re: NPE Error updating JIRA issues https://github.com/jenkinsci/jira-plugin/pull/92 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] [jira-plugin] (JENKINS-33552) Settings validation fails on JiraRestService.getMyPermissions()
Title: Message Title
Julien Carsique created an issue
Jenkins / JENKINS-33552
Settings validation fails on JiraRestService.getMyPermissions()
Issue Type:
Bug
Assignee:
Unassigned
Components:
jira-plugin
Created:
15/Mar/16 3:12 PM
Environment:
Jenkins 1.642.2 JIRA plugin 2.2 JIRA 6.3.14
Priority:
Minor
Reporter:
Julien Carsique
The new validation process introduced in version 2.1 by commit https://github.com/jenkinsci/jira-plugin/commit/1912505a9f2bc723f3910d5a4ab4da89543a721d seems not compliant with JIRA 6.3.14.
Failed to login to JIRA at https://jira.nuxeo.com/
RestClientException{statusCode=Optional.absent(), errorCollections=[]}
at com.atlassian.jira.rest.client.internal.async.DelegatingPromise.claim(DelegatingPromise.java:47)
at hudson.plugins.jira.JiraRestService.getMyPermissions(JiraRestService.java:369)
at hudson.plugins.jira.JiraSession.getMyPermissions(JiraSession.java:385)
at hudson.plugins.jira.JiraSite$DescriptorImpl.doValidate(JiraSite.java:735)
Caused by: RestClientException{statusCode=Optional.absent(), errorCollections=[]}
at com.atlassian.jira.rest.client.internal.async.AbstractAsynchronousRestClient$3.apply(AbstractAsynchronousRestClient.java:188)
at
[JIRA] [jira-plugin] (JENKINS-33551) NPE Error updating JIRA issues
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-33551 NPE Error updating JIRA issues Change By: Julien Carsique Summary: NPE Error updating JIRA issues 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] [jira-plugin] (JENKINS-33551) Error updating JIRA issues
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-33551 Error updating JIRA issues Issue Type: Bug Assignee: Unassigned Components: jira-plugin Created: 15/Mar/16 3:03 PM Environment: Jenkins 1.642.2 JIRA plugin 2.2 JIRA 6.3.14 Priority: Major Reporter: Julien Carsique An NPE is raised while updating JIRA issues. The comment is wrote on JIRA but the NPE makes the plugin continuously write the same comment and remember the issues for the next build. Error updating JIRA issues. Saving issues for next build. java.lang.NullPointerException at hudson.plugins.jira.Updater.submitComments(Updater.java:177) at hudson.plugins.jira.Updater.perform(Updater.java:128) at hudson.plugins.jira.JiraIssueUpdater.perform(JiraIssueUpdater.java:64) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:78) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:723) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1047)
[JIRA] [maven-invoker-plugin] (JENKINS-32983) Parsing Maven Invoker results from slave
Title: Message Title Julien Carsique resolved as Fixed Jenkins / JENKINS-32983 Parsing Maven Invoker results from slave Change By: Julien Carsique Status: Open Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-invoker-plugin] (JENKINS-32983) Parsing Maven Invoker results from slave
Title: Message Title Julien Carsique assigned an issue to olamy Jenkins / JENKINS-32983 Parsing Maven Invoker results from slave Change By: Julien Carsique Assignee: Julien Carsique olamy Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-invoker-plugin] (JENKINS-32983) Parsing Maven Invoker results from slave
Title: Message Title Julien Carsique commented on JENKINS-32983 Re: Parsing Maven Invoker results from slave See https://github.com/jenkinsci/maven-invoker-plugin/pull/1 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-invoker-plugin] (JENKINS-32983) Parsing Maven Invoker results from slave
Title: Message Title Julien Carsique commented on JENKINS-32983 Re: Parsing Maven Invoker results from slave This happens only with the MavenInvokerRecorder, the MavenInvokerArchiver is ok. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-invoker-plugin] (JENKINS-32983) Parsing Maven Invoker results from slave
Title: Message Title Julien Carsique stopped work on JENKINS-32983 Change By: Julien Carsique Status: In Progress Open Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-invoker-plugin] (JENKINS-32983) Parsing Maven Invoker results from slave
Title: Message Title Julien Carsique started work on JENKINS-32983 Change By: Julien Carsique Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-invoker-plugin] (JENKINS-32983) Parsing Maven Invoker results from slave
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-32983 Parsing Maven Invoker results from slave Issue Type: Bug Assignee: Julien Carsique Components: maven-invoker-plugin Created: 16/Feb/16 6:14 PM Priority: Blocker Reporter: Julien Carsique The plugin works fine on master but when the build happens on a slave, then the following error is raised at parsing the results: ERROR: Publisher org.jenkinsci.plugins.maveninvoker.MavenInvokerRecorder aborted due to exception java.io.IOException: remote file operation failed: /opt/jenkins/workspace/tools_ant-assembly-maven-plugin-master-maven-3.1/target/invoker-reports/BUILD-setup-relocated-ndt.xml at hudson.remoting.Channel@455b7688:linaws3: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@6ceda0a at org.jenkinsci.plugins.maveninvoker.MavenInvokerRecorder.perform(MavenInvokerRecorder.java:89) at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:32) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1046) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) at hudson.model.Run.execute(Run.java:1784) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by:
[JIRA] [maven-plugin] (JENKINS-19041) Can not execute Maven 3 job
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-19041 Can not execute Maven 3 job Change By: Julien Carsique Component/s: maven-plugin Component/s: maven-invoker-plugin Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-plugin] (JENKINS-19871) Maven jobs see every env variable as java properties
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-19871 Maven jobs see every env variable as java properties Change By: Julien Carsique Component/s: maven-plugin Component/s: maven-invoker-plugin Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [github-oauth-plugin] (JENKINS-21331) GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin
Title: Message Title Julien Carsique commented on JENKINS-21331 Re: GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin Sam Gleske you've closed both issues ( JENKINS-21331 and JENKINS-28575 ) as duplicate. The pull request (https://github.com/jenkinsci/github-oauth-plugin/pull/36) is not yet merged. 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] [github-oauth-plugin] (JENKINS-21331) GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin
Title: Message Title Julien Carsique commented on JENKINS-21331 Re: GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin Amending, yes of course. I'll do it today. Browsing issues in URL referencing a group, like jenkins/externalGroups/Org/Team displayed in jenkins/groups (I'm using the Role Based Access Control Plugin - http://jenkins-enterprise.cloudbees.com/docs/user-guide-docs/rbac.html). Of course it works with jenkins/externalGroups/Org*Team. I'm giving a try with %2F you suggested but I expect automated translations leading to the breaking slash in URL... we'll see. 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] [github-oauth-plugin] (JENKINS-21331) GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin
Title: Message Title Julien Carsique commented on JENKINS-21331 Re: GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin PR updated with the right JIRA ref on the last commit. I tested %2F and it does not work: auto-completion on group definition waits for %2F which is ugly. I guess * is fine even if / would be better. 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique commented on JENKINS-28575 Re: GitHub OAuth should include teams as groups Thanks for your edit, I didn't see JENKINS-21331 when I looked for an already existing issue on the same subject: your update made it clearer. Your suggestion is exactly what I've done in the pull-request, except that I couldn't use the slash (/) as a separator between Org and Team: that generates browsing issues on Jenkins side. So I choose to use an asterisk (* ; see https://github.com/jcarsique/github-oauth-plugin/commit/74f0e9eecea5f3777e7935d9e7c762f4f5f51b70#diff-8524b26b72d1d1cd6ddf1048e92b23a1R19): any character filtered out by GitHub would be convenient. 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] [github-oauth-plugin] (JENKINS-21331) GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin
Title: Message Title
Julien Carsique edited a comment on JENKINS-21331
Re: GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin
AsexplainedinJENKINS-28575:{quote}YoursuggestionisexactlywhatI'vedoneinthepull-request,exceptthatIcouldn'tusetheslash(/)asaseparatorbetweenOrgandTeam:thatgeneratesbrowsingissuesonJenkinsside.SoIchoosetouseanasterisk(*;seehttps://github.com/jcarsique/github-oauth-plugin/commit/74f0e9eecea5f3777e7935d9e7c762f4f5f51b70#diff-8524b26b72d1d1cd6ddf1048e92b23a1R19):anycharacterfilteredoutbyGitHubwouldbeconvenient.{quote} Doyouwantmetoresubmithttps://github.com/jenkinsci/github-oauth-plugin/pull/36withtherightJIRAissue?Withorwithoutthefirstformatcleanupcommit(https://github.com/jcarsique/github-oauth-plugin/commit/a310a6f0690b17d72f193827ae8f84f1ba7960da)?I'musingthesuggestedPRfortwoweeksinmycompany,withnoissue.NotethiscanbeseenasamajorsecurityfixsincethecurrentbehavioractuallygivesaccesstoGitHuborganizationsnamedOwners,Developers,Administrators...whensomeonewantstograntsitsorganizationteams.
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] [github-oauth-plugin] (JENKINS-21331) GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin
Title: Message Title Julien Carsique commented on JENKINS-21331 Re: GitHub teams should be available groups for matrix based security when using GitHub OAuth plugin Do you want me to resubmit https://github.com/jenkinsci/github-oauth-plugin/pull/36 with the right JIRA issue? With or without the first format cleanup commit ( https://github.com/jcarsique/github-oauth-plugin/commit/a310a6f0690b17d72f193827ae8f84f1ba7960da )? I'm using the suggested PR for two weeks in my company, with no issue. Note this can be seen as a major security fix since the current behavior actually gives access to GitHub organizations named Owners, Developers, Administrators... when someone wants to grants its organization teams. 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-28575 GitHub OAuth should include teams as groups Change By: Julien Carsique Priority: Minor Major 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique created an issue Jenkins / JENKINS-28575 GitHub OAuth should include teams as groups Issue Type: New Feature Assignee: Julien Carsique Components: github-oauth-plugin Created: 26/May/15 12:52 PM Priority: Minor Reporter: Julien Carsique Current implementation does not work with GitHub teams. Worse, giving access to Owners, Developers, Administrators and so on actually gives access to GitHub organizations named Owners...! Suggestion: keep GitHub organization to Jenkins group mapping add GitHub teams mapping to Jenkins group with the following form: organization*team using an asterisk as separator (any separator not allowed by GitHub in team names could be used, but the slash generates browsing errors in Jenkins).
[JIRA] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-28575 GitHub OAuth should include teams as groups Change By: Julien Carsique CurrentimplementationdoesnotworkwithGitHubteams. ItonlyincludeGitHuborganizationsasJenkinsgroups. Worse,givingaccesstoOwners,Developers,AdministratorsandsoonactuallygivesaccesstoGitHuborganizationsnamedOwners...!Suggestion:-keepGitHuborganizationtoJenkinsgroupmapping-addGitHubteamsmappingtoJenkinsgroupwiththefollowingform:organization*teamusinganasteriskasseparator(anyseparatornotallowedbyGitHubinteamnamescouldbeused,buttheslashgeneratesbrowsingerrorsinJenkins). 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique started work on JENKINS-28575 Change By: Julien Carsique Status: Open InProgress 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique commented on JENKINS-28575 Re: GitHub OAuth should include teams as groups https://github.com/jenkinsci/github-oauth-plugin/pull/36 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique assigned an issue to Sam Kottler Jenkins / JENKINS-28575 GitHub OAuth should include teams as groups Change By: Julien Carsique Assignee: JulienCarsique SamKottler 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique stopped work on JENKINS-28575 Change By: Julien Carsique Status: InProgress Open 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique updated an issue Jenkins / JENKINS-28575 GitHub OAuth should include teams as groups Change By: Julien Carsique CurrentimplementationdoesnotworkwithGitHubteams.Itonly include includes GitHuborganizationsasJenkinsgroups.Worse,givingaccesstoOwners,Developers,AdministratorsandsoonactuallygivesaccesstoGitHuborganizationsnamedOwners...!Suggestion:-keepGitHuborganizationtoJenkinsgroupmapping-addGitHubteamsmappingtoJenkinsgroupwiththefollowingform:organization*teamusinganasteriskasseparator(anyseparatornotallowedbyGitHubinteamnamescouldbeused,buttheslashgeneratesbrowsingerrorsinJenkins). 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] [github-oauth-plugin] (JENKINS-28575) GitHub OAuth should include teams as groups
Title: Message Title Julien Carsique commented on JENKINS-28575 Re: GitHub OAuth should include teams as groups Improvements (TODO): accordingly update GithubAuthorizationStrategy and GithubRequireOrganizationMembershipACL eventually add some caching with a configurable cache duration as well as a force refresh button 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] [jobconfighistory-plugin] (JENKINS-28129) Default exclusions should be more precise
Title: Message Title Julien Carsique resolved as Fixed Resolved in version 2.12. Jenkins / JENKINS-28129 Default exclusions should be more precise Change By: Julien Carsique Status: Open Resolved Assignee: MirkoFriedenhagen JulienCarsique Resolution: Fixed 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] [prioritysorter-plugin] (JENKINS-22267) Upgrade to advanced mode is somehow not persisted to disk
Title: Message Title Julien Carsique commented on JENKINS-22267 Re: Upgrade to advanced mode is somehow not persisted to disk Same issue with Jenkins 1.590 and Priority Sorter 2.9. I was not yet able to determine when it happens, nor why. I submitted JENKINS-28129 to get change history on the Priority Sorter configuration files... I've set an absolute priority up to 10 and created two JobGroups (one based on regexp, one based on view). On disk, I can see 7 jobs with priority 100, obviously not updated. I also found 3 jobs templates setting similar legacy values. Maybe that could be the cause of the issue? What happens when a job is created with a legacy priority value after migration from legacy to absolute? After manual fix of the templates job, I now have: 267 jobs with priority-2147483647/priority. What means that value? Equivalent to unset? 208 jobs with priority-1/priority 161 jobs with priority between 1 and 10 as expected. 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] [jobconfighistory-plugin] (JENKINS-28129) Default exclusions should be more precise
Julien Carsique
created JENKINS-28129
Default exclusions should be more precise
Issue Type:
Improvement
Assignee:
Mirko Friedenhagen
Components:
jobconfighistory-plugin
Created:
28/Apr/15 1:10 PM
Description:
The current default exclusion ("queue|nodeMonitors|UpdateCenter|global-build-stats") is too much wide and matches unrelated files like the jenkins.advancedqueue.* files from Priority Sorter Plugin
Project:
Jenkins
Priority:
Minor
Reporter:
Julien Carsique
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [jobconfighistory-plugin] (JENKINS-28129) Default exclusions should be more precise
Julien Carsique commented on JENKINS-28129 Default exclusions should be more precise https://github.com/jenkinsci/jobConfigHistory-plugin/pull/43 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] [junit] (JENKINS-24655) Maven Job use of testFailureIgnore option should be configurable or avoided
Julien Carsique created JENKINS-24655 Maven Job use of testFailureIgnore option should be configurable or avoided Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: junit, maven Created: 10/Sep/14 3:42 PM Description: I understood from various emails, issues, discussions and source code that it is a wanted behavior to set a build UNSTABLE when (surefire or failsafe) tests fail. That is consistent with https://wiki.jenkins-ci.org/display/JENKINS/Terminology However, the current behavior is error-prone and inconsistent with a command line or Freestyle job Maven execution. I guess that if the UNSTABLE status was that much important, it would have been implemented on Freestyle jobs too. Especially since Freestyle are so often recommended rather than the useful Maven job. Problem First main issue is the build continuation. Second issue is the behavior difference between Maven and Freestyle jobs. Freestyle job The result is the same as an execution from command line: Maven execution is interrupted Maven build is FAILURE Jenkins build is FAILURE Reproducing the Maven job behavior is partially possible with -Dmaven.test.failure.ignore=true option and the use of 'Publish JUnit test result report' post build step (to change the build result from SUCCESS to UNSTABLE). Maven job The result is similar to using the -Dmaven.test.failure.ignore=true option: the Maven execution is not interrupted Maven build is SUCCESS Jenkins build is UNSTABLE Responsible code is there: https://github.com/jenkinsci/maven-plugin/blob/maven-plugin-2.6/src/main/java/hudson/maven/reporters/SurefireArchiver.java#L88 The main issue is the build continuation, which will for instance install the artifacts: [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ test-jenkins-failures --- [ERROR] There are test failures. [INFO] --- maven-failsafe-plugin:2.17:integration-test (default) @ test-jenkins-failures --- [INFO] --- maven-failsafe-plugin:2.17:verify (default) @ test-jenkins-failures --- [ERROR] There are test failures. [INFO] --- maven-install-plugin:2.5.1:install (default-install) @ test-jenkins-failures --- [INFO] Installing ... [INFO] BUILD SUCCESS Finished: UNSTABLE ḧ3. Solutions Add an option for ignoring or not the test failures during the build. An option would highlight that behavior and allow to easily switch from a testFailureIgnore mode to a standard mode. Rather use -fae Maven 3 option, or improve current implementation not to use the testFailureIgnore property hack -fae,--fail-at-end Only fail the build afterwards; allow all non-impacted builds to continue That would not be the exact equivalent to the current implementation but would still allow to get a status on multiple modules and would only require to "catch" the Maven failure at the end of the build. Having a final Maven build FAILED translated to Jenkins build UNSTABLE would avoid the unwanted execution of other plugins after surefire or failsafe detected the failure. Consistency with Freestyle job For consistency purpose, the 'Publish JUnit test result report' post build step should be able to switch the Jenkins build result from FAILURE to UNSTABLE when the BUILD failure is only due to Maven tests failure. Environment: Jenkins 1.578 Project: Jenkins Priority: Minor Reporter: Julien Carsique This message is automatically generated by JIRA. If you think it was sent incorrectly, please
[JIRA] [junit] (JENKINS-24655) Maven Job use of testFailureIgnore option should be configurable or avoided
Julien Carsique
updated JENKINS-24655
Maven Job use of testFailureIgnore option should be configurable or avoided
Change By:
Julien Carsique
(10/Sep/14 3:42 PM)
Description:
Iunderstoodfromvariousemails,issues,discussionsandsourcecodethatitisawantedbehaviortosetabuildUNSTABLEwhen(surefireorfailsafe)testsfail.Thatisconsistentwithhttps://wiki.jenkins-ci.org/display/JENKINS/TerminologyHowever,thecurrentbehavioriserror-proneandinconsistentwithacommandlineorFreestylejobMavenexecution.IguessthatiftheUNSTABLEstatuswasthatmuchimportant,itwouldhavebeenimplementedonFreestylejobstoo.EspeciallysinceFreestylearesooftenrecommendedratherthantheusefulMavenjob.h3.ProblemFirstmainissueisthebuildcontinuation.SecondissueisthebehaviordifferencebetweenMavenandFreestylejobs.h4.FreestylejobTheresultisthesameasanexecutionfromcommandline:-Mavenexecutionisinterrupted-MavenbuildisFAILURE-JenkinsbuildisFAILUREReproducingtheMavenjobbehaviorispartiallypossiblewith{{-Dmaven.test.failure.ignore=true}}optionandtheuseofPublishJUnittestresultreportpostbuildstep(tochangethebuildresultfromSUCCESStoUNSTABLE).h4.MavenjobTheresultissimilartousingthe{{-Dmaven.test.failure.ignore=true}}option:-*theMavenexecutionisnotinterrupted*-MavenbuildisSUCCESS-JenkinsbuildisUNSTABLEResponsiblecodeisthere:https://github.com/jenkinsci/maven-plugin/blob/maven-plugin-2.6/src/main/java/hudson/maven/reporters/SurefireArchiver.java#L88Themainissueisthebuildcontinuation,whichwillforinstanceinstalltheartifacts:{noformat}[INFO]---maven-surefire-plugin:2.17:test(default-test)@test-jenkins-failures---[ERROR]Therearetestfailures.[INFO]---maven-failsafe-plugin:2.17:integration-test(default)@test-jenkins-failures---[INFO]---maven-failsafe-plugin:2.17:verify(default)@test-jenkins-failures---[ERROR]Therearetestfailures.[INFO]---maven-install-plugin:2.5.1:install(default-install)@test-jenkins-failures---[INFO]Installing...[INFO]BUILDSUCCESSFinished:UNSTABLE{noformat}
ḧ3
h3
.Solutionsh4.Addanoptionforignoringornotthetestfailuresduringthebuild.AnoptionwouldhighlightthatbehaviorandallowtoeasilyswitchfromatestFailureIgnoremodetoastandardmode.h4.Ratheruse{{-fae}}Maven3option,orimprovecurrentimplementationnottousethetestFailureIgnorepropertyhack{noformat}-fae,--fail-at-endOnlyfailthebuildafterwards;allowallnon-impactedbuildstocontinue{noformat}ThatwouldnotbetheexactequivalenttothecurrentimplementationbutwouldstillallowtogetastatusonmultiplemodulesandwouldonlyrequiretocatchtheMavenfailureattheendofthebuild.HavingafinalMavenbuildFAILEDtranslatedtoJenkinsbuildUNSTABLEwouldavoidtheunwantedexecutionofotherpluginsaftersurefireorfailsafedetectedthefailure.h4.ConsistencywithFreestylejobForconsistencypurpose,thePublishJUnittestresultreportpostbuildstepshouldbeabletoswitchtheJenkinsbuildresultfromFAILUREtoUNSTABLEwhentheBUILDfailureisonlyduetoMaventestsfailure.
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] [junit] (JENKINS-12869) Maven Build fails when integration/system test executed with failsafe fails.
Julien Carsique resolved JENKINS-12869 as Cannot Reproduce Maven Build fails when integration/system test executed with failsafe fails. Not the case anymore (Jenkins 1.578, Maven 3.2.3, maven-failsafe-plugin 2.17). Failsafe and Surefire behave the same. Note however JENKINS-24655 (I think the right fix would have been to make Surefire behave the same as Failsafe and fail the build...). Change By: Julien Carsique (10/Sep/14 3:47 PM) Status: Open Resolved Resolution: CannotReproduce 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] [junit] (JENKINS-24655) Maven Job use of testFailureIgnore option should be configurable
Julien Carsique
updated JENKINS-24655
Maven Job use of testFailureIgnore option should be configurable
EDIT
Changed from bug to improvement: that is not a bug. Changed the title and description. My mistake came from the following output in the console after having encountered false-positive errors due to the TASK and DRY plugins upgrade (I first though it was another similar issue):
[ERROR] There are test failures.
[INFO] BUILD SUCCESS
Finished: UNSTABLE
Change By:
Julien Carsique
(10/Sep/14 11:34 PM)
Summary:
MavenJobuseoftestFailureIgnoreoptionshouldbeconfigurable
oravoided
Issue Type:
Bug
Improvement
Description:
Iunderstoodfromvariousemails,issues,discussionsandsourcecodethatitisawantedbehaviortosetabuildUNSTABLEwhen(surefireorfailsafe)testsfail.Thatisconsistentwith
FollowingtheJenkins[Terminology|
https://wiki.jenkins-ci.org/display/JENKINS/Terminology
However
]
,
when(surefireorfailsafe)testsfail,
the
currentbehavior
JenkinsbuildstatusmustbeUNSTABLE:Abuild
is
error-prone
unstableifitwasbuiltsuccessfully
and
inconsistentwithacommandline
one
or
FreestylejobMavenexecution
morepublishersreportitunstable
.
Iguessthat
Forexample
ifthe
UNSTABLEstatuswasthatmuchimportant,itwouldhavebeenimplementedonFreestylejobstoo.EspeciallysinceFreestylearesooftenrecommendedratherthantheusefulMavenjob.h3.ProblemFirstmainissue
JUnitpublisher
is
configuredandatestfailsthen
thebuild
continuation
willbemarkedunstable
.
SecondissueisthebehaviordifferencebetweenMavenandFreestylejobs.
h4.
Freestyle
Maven
job
Theresult
That
isthe
sameasanexecutionfromcommandline
defaultcaseonMavenjobs;thecodeofhttps
:
//github.com/jenkinsci/maven
-
Mavenexecutionisinterrupted
plugin/blob/maven
-
MavenbuildisFAILURE
plugin
-
JenkinsbuildisFAILUREReproducingtheMavenjobbehaviorispartiallypossiblewith{{-Dmaven
2
.
test
6/src/main/java/hudson/maven/reporters/SurefireArchiver
.
failure.ignore=true}}optionand
java#L88uses
the
useofPublishJUnittestresultreportpostbuildstep(tochangethebuildresultfromSUCCESStoUNSTABLE).h4.MavenjobTheresultissimilartousingthe
{{-Dmaven.test.failure.ignore=true}}option:-*theMavenexecutionisnotinterrupted
byatestfailure
*-MavenbuildisSUCCESS-JenkinsbuildisUNSTABLE
Responsiblecode
However,that
is
there:https://github
afewerror-proneandinconsistentwiththecommandlineorFreestylejobMavenexecution
.
com/jenkinsci/maven
ThatwouldbehighlightedbyaJenkinsoptiontoswitchonoroffthatfeature,ratherthantheneedtoknowonemustpass{{
-
plugin/blob/maven-plugin-2
Dmaven
.
6/src/main/java/hudson/maven/reporters/SurefireArchiver
test
.
java#L88
failure.ignore=false}}todeactivateit.
The
mainissueis
error-proneaspectcomesfrom
thebuildcontinuation,whichwillforinstanceinstalltheartifacts:{noformat}[INFO]---maven-surefire-plugin:2.17:test(default-test)@test-jenkins-failures---[ERROR]Therearetestfailures.[INFO]---maven-failsafe-plugin:2.17:integration-test(default)@test-jenkins-failures---[INFO]---maven-failsafe-plugin:2.17:verify(default)@test-jenkins-failures---[ERROR]Therearetestfailures.[INFO]---maven-install-plugin:2.5.1:install(default-install)@test-jenkins-failures---[INFO]Installing...[INFO]BUILDSUCCESSFinished:UNSTABLE{noformat}
h3.Solutionsh4.Addanoptionforignoring
So,itisrecommendedinaMavenjobtocallthe{{package}phaseratherthan{{install}}
or
not
{{deploy}}anduse
the
testfailuresduringthe
post-
build
stepstodeploytheartifactsattheend(thenewdeployAtEndMavenoptionisanalternative)
.
Anoption
It
would
highlightthatbehaviorandallowtoeasilyswitchfrom
beniceiftherewas
a
testFailureIgnoremode
way
to
astandardmode.h4.Rather
alternatively
use
forinstancethe
{{-fae}}Maven3option
,orimprovecurrentimplementationnottousethetestFailureIgnorepropertyhack{noformat}-fae,--fail-at-end
(
Onlyfailthebuildafterwards;allowallnon-impactedbuildstocontinue
{noformat}Thatwouldnotbetheexactequivalenttothecurrentimplementationbutwouldstillallowtogetastatusonmultiplemodulesandwouldonlyrequireto
catch
)andget
the
Mavenfailureattheendofthebuild.Havinga
[JIRA] [junit] (JENKINS-24655) Maven Job use of testFailureIgnore option should be configurable
Julien Carsique
updated JENKINS-24655
Maven Job use of testFailureIgnore option should be configurable
Change By:
Julien Carsique
(10/Sep/14 11:38 PM)
Description:
FollowingtheJenkins[Terminology|https://wiki.jenkins-ci.org/display/JENKINS/Terminology],when(surefireorfailsafe)testsfail,theJenkinsbuildstatusmustbeUNSTABLE:Abuildisunstableifitwasbuiltsuccessfullyandoneormorepublishersreportitunstable.ForexampleiftheJUnitpublisherisconfiguredandatestfailsthenthebuildwillbemarkedunstable.h4.MavenjobThatisthedefaultcaseonMavenjobs;thecodeofhttps://github.com/jenkinsci/maven-plugin/blob/maven-plugin-2.6/src/main/java/hudson/maven/reporters/SurefireArchiver.java#L88usesthe{{-Dmaven.test.failure.ignore=true}}option:-*theMavenexecutionisnotinterruptedbyatestfailure*-MavenbuildisSUCCESS-JenkinsbuildisUNSTABLEHowever,thatisafewerror-proneandinconsistentwiththecommandlineorFreestylejobMavenexecution.ThatwouldbehighlightedbyaJenkinsoptiontoswitchonoroffthatfeature,ratherthantheneedtoknowonemustpass{{-Dmaven.test.failure.ignore=false}}todeactivateit.Theerror-proneaspectcomesfromthebuildcontinuation,whichwillforinstanceinstalltheartifacts:{noformat}[INFO]---maven-surefire-plugin:2.17:test(default-test)@test-jenkins-failures---[ERROR]Therearetestfailures.[INFO]---maven-failsafe-plugin:2.17:integration-test(default)@test-jenkins-failures---[INFO]---maven-failsafe-plugin:2.17:verify(default)@test-jenkins-failures---[ERROR]Therearetestfailures.[INFO]---maven-install-plugin:2.5.1:install(default-install)@test-jenkins-failures---[INFO]Installing...[INFO]BUILDSUCCESSFinished:UNSTABLE{noformat}So,itisrecommendedinaMavenjobtocallthe{{package}
phase
}or{{verify}}phases
ratherthan{{install}}or{{deploy}}andusethepost-buildstepstodeploytheartifactsattheend(thenewdeployAtEndMavenoptionisanalternative).Itwouldbeniceiftherewasawaytoalternativelyuseforinstancethe{{-
Dmaven.test.failure.ignore=false}}parameterandthe{{-
fae}}Maven3option(Onlyfailthebuildafterwards;allowallnon-impactedbuildstocontinue)
and
but
getthefinalMavenbuildFAILEDtranslatedtoJenkinsbuildUNSTABLE.
Forconsistencywiththeterminology
.
.
h4.FreestylejobAbouttheMavenbuildstepinFreestylejobs,theydonotbehavethatwaybydefault.Theresultisthesameasanexecutionfromcommandline:-Mavenexecutionisinterruptedbytestsfailures-MavenbuildisFAILURE-JenkinsbuildisFAILUREReproducingtheMavenjobbehaviorispossiblewiththe{{-Dmaven.test.failure.ignore=true}}optionandtheuseofPublishJUnittestresultreportpostbuildstep(tochangethebuildresultfromSUCCESStoUNSTABLE).AsfortheMavenjob,itwouldbegreatifthePublishJUnittestresultreportpostbuildstepwouldbeabletoswitchtheJenkinsbuildresultfromFAILUREtoUNSTABLEwhentheBUILDfailureisonlyduetoMaventestfailures.
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] [junit] (JENKINS-12869) Maven Build fails when integration/system test executed with failsafe fails.
Julien Carsique edited a comment on JENKINS-12869 Maven Build fails when integration/system test executed with failsafe fails. Not the case anymore (Jenkins 1.578, Maven 3.2.3, maven-failsafe-plugin 2.17). Failsafe and Surefire behave the same. Note that with Maven build step in Freestyle jobs, that behavior requires the -Dmaven.test.failure.ignore=true option and the 'Publish JUnit test result report' post build step (JENKINS-24655) 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] (JENKINS-22252) Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap
Julien Carsique commented on JENKINS-22252 Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap @marc321 there's nothing a user can do, your comment is out of purpose: using Maven 3.2.1 in a Maven job type, the console is full of the described stacktrace. As explained @jglick this does not happen with Maven 3.1.1. 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] (JENKINS-11695) Jenkins does not respect Maven profiles - so pom module parsing fails
Julien Carsique
commented on JENKINS-11695
Jenkins does not respect Maven profiles - so pom module parsing fails
Confirmed with a repository added from a profile and containing an updated parent POM, providing a new dependency in its dependencyManagement.
The POM parsing fails with "'dependencies.dependency.version' for org.quartz-scheduler:quartz-oracle:jar is missing".
This error corresponds to not using the profile configured in the job ("qa" in my case):
$ mvn help:effective-pom -Pqa |grep -C2 quartz-oracle
dependency
groupIdorg.quartz-scheduler/groupId
artifactIdquartz-oracle/artifactId
version1.8.6/version
/dependency
$ mvn help:effective-pom |grep -C2 quartz-oracle
Validation Messages:
[0] 'dependencies.dependency.version' is missing for org.quartz-scheduler:quartz-oracle:jar
The suggested workaround, I saw in some mailing list thread, to provide a custom settings which activates the wanted profile doesn't work neither.
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] [ec2] (JENKINS-20789) EC2: manage new computeCurrentGen (c3.*) instances
Julien Carsique resolved JENKINS-20789 as Fixed EC2: manage new computeCurrentGen (c3.*) instances Change By: Julien Carsique (28/Nov/13 1:11 PM) 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/groups/opt_out.
[JIRA] [ec2] (JENKINS-20789) EC2: manage new computeCurrentGen (c3.*) instances
Julien Carsique created JENKINS-20789 EC2: manage new computeCurrentGen (c3.*) instances Issue Type: New Feature Assignee: Julien Carsique Components: ec2 Created: 27/Nov/13 1:47 PM Description: Align on com.amazonaws:aws-java-sdk:1.6.7 to manage new "computeCurrentGen" (aka "c3.*") instances. Project: Jenkins Priority: Major Reporter: Julien Carsique 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] [ec2] (JENKINS-20789) EC2: manage new computeCurrentGen (c3.*) instances
Julien Carsique started work on JENKINS-20789 EC2: manage new computeCurrentGen (c3.*) instances Change By: Julien Carsique (27/Nov/13 2:00 PM) Status: Open InProgress 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] [ec2] (JENKINS-20789) EC2: manage new computeCurrentGen (c3.*) instances
Julien Carsique commented on JENKINS-20789 EC2: manage new computeCurrentGen (c3.*) instances https://github.com/jenkinsci/ec2-plugin/pull/71 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] [ec2] (JENKINS-20789) EC2: manage new computeCurrentGen (c3.*) instances
Julien Carsique stopped work on JENKINS-20789 EC2: manage new computeCurrentGen (c3.*) instances Change By: Julien Carsique (27/Nov/13 4:28 PM) Status: InProgress Open 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] [global-build-stats] (JENKINS-17248) java.lang.NullPointerException by start
Julien Carsique updated JENKINS-17248 java.lang.NullPointerException by start Attached a backup of global-build-stats.xml but I didn't test if it reproduces the issue. Change By: Julien Carsique (16/Jun/13 2:24 PM) Attachment: global-build-stats.xml 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] [global-build-stats] (JENKINS-17248) java.lang.NullPointerException by start
Julien Carsique commented on JENKINS-17248 java.lang.NullPointerException by start It's a global-build-stats configuration forward compliance issue. Fix by removing (or rename for backup) .jenkins/global-build-stats.xml. 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-14332) Repeated channel/timeout errors from Jenkins slave
Julien Carsique edited a comment on JENKINS-14332 Repeated channel/timeout errors from Jenkins slave Maybe not a Jenkins issue. Having the same issue, reproduced at every build for a given slave (but with nothing relevant in its logs), I tried to disconnect and reconnect the slave: [05/06/13 14:06:04] Launching slave agent $ ssh slavedns java -jar ~/bin/slave.jar ===[JENKINS REMOTING CAPACITY]==[JENKINS REMOTING CAPACITY]===channel started channel started Slave.jar version: 2.22 This is a Unix slave Slave.jar version: 2.22 This is a Unix slave Copied maven-agent.jar Copied maven3-agent.jar Copied maven3-interceptor.jar Copied maven-agent.jar Copied maven-interceptor.jar Copied maven2.1-interceptor.jar Copied plexus-classworld.jar Copied maven3-agent.jar Copied maven3-interceptor.jar Copied classworlds.jar Copied maven-interceptor.jar Copied maven2.1-interceptor.jar Copied plexus-classworld.jar Copied classworlds.jar Evacuated stdout Evacuated stdout ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins (...)java.lang.IllegalStateException: Already connected at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:459) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:339) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:122) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:222) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Connection terminated channel stopped ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins (...)java.lang.NullPointerException at org.jenkinsci.modules.slave_installer.impl.ComputerListenerImpl.onOnline(ComputerListenerImpl.java:32) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:471) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:339) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:122) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:222) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) channel stopped Connection terminated Then the slaved successfully reconnected itself. It appeared there was looping thread consuming 100% CPU. Killing the process solved the issue. Strangely, some system and Java commands were not working (ps, cat, less, jstack, trace, ...) until it has been killed, whereas other commands worked (top, jps, renice, kill, ...). That could explain the weird Jenkins 4s timeout log (java.util.concurrent.TimeoutException: Ping started on 1367743028681 hasn't completed at 1367743268682): the system was partially frozen and with really unstable response times. 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-14332) Repeated channel/timeout errors from Jenkins slave
Julien Carsique edited a comment on JENKINS-14332 Repeated channel/timeout errors from Jenkins slave Maybe not a Jenkins issue. Having the same issue, reproduced at every build for a given slave (but with nothing relevant in its logs), I tried to disconnect and reconnect the slave: [05/06/13 14:06:04] Launching slave agent $ ssh slavedns java -jar ~/bin/slave.jar ===[JENKINS REMOTING CAPACITY]==[JENKINS REMOTING CAPACITY]===channel started channel started Slave.jar version: 2.22 This is a Unix slave Slave.jar version: 2.22 This is a Unix slave Copied maven-agent.jar Copied maven3-agent.jar Copied maven3-interceptor.jar Copied maven-agent.jar Copied maven-interceptor.jar Copied maven2.1-interceptor.jar Copied plexus-classworld.jar Copied maven3-agent.jar Copied maven3-interceptor.jar Copied classworlds.jar Copied maven-interceptor.jar Copied maven2.1-interceptor.jar Copied plexus-classworld.jar Copied classworlds.jar Evacuated stdout Evacuated stdout ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins (...)java.lang.IllegalStateException: Already connected at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:459) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:339) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:122) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:222) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Connection terminated channel stopped ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins (...)java.lang.NullPointerException at org.jenkinsci.modules.slave_installer.impl.ComputerListenerImpl.onOnline(ComputerListenerImpl.java:32) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:471) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:339) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:122) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:222) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) channel stopped Connection terminated Then the slaved successfully reconnected itself. It appeared there was looping thread consuming 100% CPU. Killing the process solved the issue. Strangely, some system and Java commands were not working (ps, cat, less, jstack, trace, ...) until it has been killed, whereas other commands worked (top, jps, renice, kill, ...). That could explain the weird Jenkins 4s timeout log (java.util.concurrent.TimeoutException: Ping started on 1367743028681 hasn't completed at 1367743268682): the system was partially frozen and with really unstable response times. Note the looping thread came from a previous job which badly stopped on timeout: 03:00:16.868 Build timed out (after 180 minutes). Marking the build as aborted. 03:00:16.873 Build was aborted 03:00:16.874 Archiving artifacts 03:00:16.874 ERROR: Failed to archive artifacts: **/log/*.log, tomcat*/nxserver/config/distribution.properties 03:00:16.875 hudson.remoting.ChannelClosedException: channel is already closed 03:00:16.876 at hudson.remoting.Channel.send(Channel.java:494) 03:00:16.876 at hudson.remoting.Request.call(Request.java:129) 03:00:16.876 at hudson.remoting.Channel.call(Channel.java:672) 03:00:16.876 at hudson.EnvVars.getRemote(EnvVars.java:212) 03:00:16.876 at hudson.model.Computer.getEnvironment(Computer.java:882) 03:00:16.876 at jenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:28) 03:00:16.876 at hudson.model.Run.getEnvironment(Run.java:2028) 03:00:16.876 at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:927) 03:00:16.876 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:115) 03:00:16.876 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) 03:00:16.876 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:798) 03:00:16.876 at
[JIRA] [timestamper] (JENKINS-17697) Different timestamp between short and full console log on timeout
Julien Carsique created JENKINS-17697 Different timestamp between short and full console log on timeout Issue Type: Bug Assignee: stevengbrown Components: timestamper Created: 22/Apr/13 12:22 PM Description: When a timeout occurs, it seems the timestamp shown in the short console log is sometimes wrong. Whereas it's right on the full console log. Extract from /console 07:53:24 == 07:53:24 Build timed out (after 300 minutes). Marking the build as aborted. 07:53:24 Build was aborted 07:53:24 Recording test results 11:02:31 [ci-game] evaluating rule: Build result Extract from /consoleFull 07:53:24 == 11:02:31 Build timed out (after 300 minutes). Marking the build as aborted. 11:02:31 Build was aborted 11:02:31 Recording test results 11:02:31 [ci-game] evaluating rule: Build result The right one must be the consoleFull since the timeout occurred at 11h02, not 07:53. Project: Jenkins Priority: Minor Reporter: Julien Carsique 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-17123) Also state the committer id when it differs from the pusher id
Julien Carsique created JENKINS-17123 Also state the committer id when it differs from the pusher id Issue Type: Improvement Assignee: Unassigned Components: jira Created: 07/Mar/13 5:38 PM Description: This obviously won't apply to all SCMs. For instance, the following commit https://github.com/nuxeo/nuxeo-asset-browser/commit/12b8b204a43b1927798b3b6303a00634e650a49d will generate the following Jira comment: NXP-11029: fix reRender ids (atchertchian: 12b8b204a43b1927798b3b6303a00634e650a49d) It would be great to see in such cases (merge, cherry-pick, ...) something like: NXP-11029: fix reRender ids (troger authored, atchertchian committed: 12b8b204a43b1927798b3b6303a00634e650a49d) Project: Jenkins Priority: Minor Reporter: Julien Carsique 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-16933) Make Jira plugin write more compact comments
Julien Carsique created JENKINS-16933 Make Jira plugin write more compact comments Issue Type: Improvement Assignee: Julien Carsique Components: jira Created: 22/Feb/13 5:21 PM Description: The comments written by the Jira plugin are useful but takes too much space, reducing the whole history readability. Also, we need a browser link to the changeset; that is currently only available when activating the recordScmChanges option (which is really verbose). Current style Integrated in nuxeo-distribution-master #1399 NXP-11039 - Log STDERR in case of JVM launch issue (Revision 4c335fd87af6dd98e7d84de7a06009800d928817) Result = SUCCESS New style SUCCESS: Integrated in nuxeo-distribution-master #1399 NXP-11039 - Log STDERR in case of JVM launch issue (jcarsique: 4c335fd87af6dd98e7d84de7a06009800d928817) Project: Jenkins Priority: Minor Reporter: Julien Carsique 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-16933) Make Jira plugin write more compact comments
Julien Carsique commented on JENKINS-16933 Make Jira plugin write more compact comments About the changed files list (recordScmChanges option), it would be great to write them collapsed by default but the only current Wiki solution seems to be a custom macro so I didn't change them. Note however, the refactoring I did changed the order: files are now listed right after the corresponding aggregated comment whereas before that change, they were listed after the initial list of aggregated comments. I guess it's a trivial and acceptable change. 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-16933) Make Jira plugin write more compact comments
Julien Carsique edited a comment on JENKINS-16933 Make Jira plugin write more compact comments https://github.com/jenkinsci/jira-plugin/pull/18 About the changed files list (recordScmChanges option), it would be great to write them collapsed by default but the only current Wiki solution seems to be a custom macro so I didn't change them. Note however, the refactoring I did changed the order: files are now listed right after the corresponding aggregated comment whereas before that change, they were listed after the initial list of aggregated comments. I guess it's a trivial and acceptable change. 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-16933) Make Jira plugin write more compact comments
Julien Carsique reopened JENKINS-16933 Make Jira plugin write more compact comments Change By: Julien Carsique (22/Feb/13 6:23 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] (JENKINS-16933) Make Jira plugin write more compact comments
Julien Carsique resolved JENKINS-16933 as Fixed Make Jira plugin write more compact comments Using a custom build 1.36-SNAPSHOT waiting for pull-request merge. See https://issues.jenkins-ci.org/browse/JENKINS-16933 Change By: Julien Carsique (22/Feb/13 6:23 PM) 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/groups/opt_out.
[JIRA] (JENKINS-16933) Make Jira plugin write more compact comments
Julien Carsique updated JENKINS-16933 Make Jira plugin write more compact comments Change By: Julien Carsique (22/Feb/13 6:24 PM) Status: Reopened Open 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-16933) Make Jira plugin write more compact comments
Julien Carsique edited a comment on JENKINS-16933 Make Jira plugin write more compact comments (deleted) 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-16933) Make Jira plugin write more compact comments
Julien Carsique resolved JENKINS-16933 as Fixed Make Jira plugin write more compact comments Merged in 1.36. Change By: Julien Carsique (22/Feb/13 10:26 PM) 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/groups/opt_out.
[JIRA] (JENKINS-12818) Fix Linux mouse paste in the description fields
Julien Carsique resolved JENKINS-12818 as Cannot Reproduce Fix Linux mouse paste in the description fields Not reproducible with 1.500 Change By: Julien Carsique (18/Feb/13 1:21 PM) Status: Open Resolved Resolution: CannotReproduce 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-15237) Dependent Maven Jobs ignore version-number
Julien Carsique commented on JENKINS-15237 Dependent Maven Jobs ignore version-number Complementary info: not specific to Windows, nor Maven 3; reproduced on Linux, Maven 2.2.1, Jenkins 1.481 to 1.491 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-15237) Dependent Maven Jobs ignore version-number
Julien Carsique edited a comment on JENKINS-15237 Dependent Maven Jobs ignore version-number Great to see it fixed in JENKINS-15367, for 1.492 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-15367) Jenkins kicks off the wrong downstream builds for Maven
Julien Carsique commented on JENKINS-15367 Jenkins kicks off the wrong downstream builds for Maven Successfully tested on 1.491 with a cherry-pick of 4043905580df5bf22cde0eaf3dec103abdc88017 I tried with https://github.com/nuxeo/nuxeo-common/ and https://github.com/nuxeo/nuxeo-runtime/ with their "master" and "5.6.0" branches. I couldn't try much more with https://github.com/vietj/chromattic and https://github.com/vietj/wikbook because of build issues but it seems fine on the POM parsing part. Before the fix, nuxeo-common master (version 5.7-SNAPSHOT) was triggering nuxeo-runtime master (version 5.7-SNAPSHOT) and 5.6.0 (version 5.6.0-HF04-SNAPSHOT), whereas nuxeo-common 5.6.0 was triggering nothing at all. Note I didn't try to reproduce the issue with chromattic and wikbook before the fix. However, even if the triggering is fixed, I still have an issue (I don't know if it's exactly the same issue): relationship between builds is sticked at builds earlier the fix if there was no build before the fix, then the relationship is empty I'm talking about jenkins/projectRelationship?lhs=nuxeo-common-5.6.0rhs=nuxeo-runtime-5.6.0 and jenkins/projectRelationship?lhs=nuxeo-common-masterrhs=nuxeo-runtime-master Before 1.480, the relationship is right. Since 1.481 until 1.491, without the current fix, the relationship seems still right even if triggering is wrong (see comment-168178 on JENKINS-15237). With the current fix applied on 1.491, the relationship is no more updated (new builds are ignored). Of course, that new issue appears on the summary views: upstream/downstream information on jobs is right whereas upstream/downstream information on builds is simply missing. 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-15651) Workaround GitHub connection issues
Julien Carsique created JENKINS-15651 Workaround GitHub connection issues Issue Type: Improvement Assignee: Unassigned Components: github Created: 29/Oct/12 10:53 AM Description: GitHub often has connection issues making the build fails for bad reasons. The workaround we currently apply on https://qa.nuxeo.org/jenkins/job/addons-master/ is to rebuild up to 5 times, using "Retry build after failure", when the regexp ".*GitException: Could not fetch from any repository" matches the logs. Such error could be easier detected by the GitHub plugin and the "retry" workaround being automatically applied. Project: Jenkins Priority: Major Reporter: Julien Carsique 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-15418) Git fails to clean windows workspace with long path
Julien Carsique commented on JENKINS-15418 Git fails to clean windows workspace with long path Hi, Thanks for that interesting link. You're right and we already worked on shortening our paths. We also wrote a few scripts which automatically map the current path on a new drive letter in order to reduce the risk to encounter that ridiculous Windows issue. But anything we do is only delaying the issue. And it came back with that job. The point here is: the job is a "matrix" job so the working dir path is longer (C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS). Reducing too much the job name is an issue when you have 400 jobs. in the currently failing path, the only part we could still reduce is not very long: nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss. The deletion fails in Java File.delete() so there's no quick solution for that issue. But we could imagine some workarounds to reduce the times it's happening: Jenkins could mount the working directory on a new drive letter, Jenkins could propose to use a specific short path when on Windows (ie c:\ws\buildNumber or c:\ws\jobName\buildNumber), when failing to delete a file on Windows, the code could try to fallback on calling a delete windows command (rmdir /s /q path/to/file), ... I can't see a "clean" solution but anything that could help to shorten the path when working on windows would help... 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-15418) Fails to clean windows workspace with long path
Julien Carsique
updated JENKINS-15418
Fails to clean windows workspace with long path
Change By:
Julien Carsique
(22/Oct/12 9:30 AM)
Summary:
Gitfails
Fails
tocleanwindowsworkspacewithlongpath
Priority:
Major
Minor
Description:
Iseethatissuehappeningonlongpaths.Aworkaroundwastousedrivemappinginordertoreducethelengthbutitdoesntsolvetheissueandwecametothelimitofpathshorteningpossibilities.HeresastacktracefromaMatrixjob:https://qa.nuxeo.org/jenkins/job/nuxeo-master-fullbuild-part2-distribution-multios/218/Slave=MULTIDB_WINDOWS{code}08:59:26BuildingremotelyontweedleduminworkspaceC:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS08:59:26Checkout:MULTIDB_WINDOWS/C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS-hudson.remoting.Channel@4a58a509:tweedledum08:59:26Usingstrategy:Default08:59:26LastBuiltRevision:Revision3676821964588c85aa8b71e288c743c24edd00a3(origin/master)08:59:27CloningtheremoteGitrepository08:59:27Cloningrepositorygit://github.com/nuxeo/nuxeo-distribution.git08:59:27git--version08:59:27gitversion1.7.6.msysgit.008:59:27ERROR:Failedtocleantheworkspace08:59:27java.io.IOException:UnabletodeleteC:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management-filesindir:[C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management\pom.properties,C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management\pom.xml]08:59:27 athudson.Util.deleteFile(Util.java:238)08:59:27 athudson.Util.deleteRecursive(Util.java:289)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 athudson.Util.deleteRecursive(Util.java:280)08:59:27 athudson.FilePath$11.invoke(FilePath.java:910)08:59:27 athudson.FilePath$11.invoke(FilePath.java:908)08:59:27 athudson.FilePath.act(FilePath.java:842)08:59:27 athudson.FilePath.act(FilePath.java:824)08:59:27 athudson.FilePath.deleteRecursive(FilePath.java:908)08:59:27 athudson.plugins.git.GitAPI.clone(GitAPI.java:239)08:59:27 athudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1040)08:59:27 athudson.plugins.git.GitSCM$2.invoke(GitSCM.java:982)08:59:27
[JIRA] (JENKINS-15418) Fails to clean windows workspace with long path
Julien Carsique commented on JENKINS-15418 Fails to clean windows workspace with long path Interesting solution. I commented your commit with my tests results: https://github.com/onemanbucket/jenkins/commit/0ab18187eb60dd89cf5759eb231c326cb31c866b#commitcomment-2033773 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-15418) Git fails to clean windows workspace with long path
Julien Carsique created JENKINS-15418 Git fails to clean windows workspace with long path Issue Type: Bug Assignee: Nicolas De Loof Attachments: config.xml Components: git Created: 05/Oct/12 10:28 AM Description: I see that issue happening on long paths. A workaround was to use drive mapping in order to reduce the length but it doesn't solve the issue and we came to the limit of path shortening possibilities. Here's a stacktrace from a Matrix job: https://qa.nuxeo.org/jenkins/job/nuxeo-master-fullbuild-part2-distribution-multios/218/Slave=MULTIDB_WINDOWS 08:59:26 Building remotely on tweedledum in workspace C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS 08:59:26 Checkout:MULTIDB_WINDOWS / C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS - hudson.remoting.Channel@4a58a509:tweedledum 08:59:26 Using strategy: Default 08:59:26 Last Built Revision: Revision 3676821964588c85aa8b71e288c743c24edd00a3 (origin/master) 08:59:27 Cloning the remote Git repository 08:59:27 Cloning repository git://github.com/nuxeo/nuxeo-distribution.git 08:59:27 git --version 08:59:27 git version 1.7.6.msysgit.0 08:59:27 ERROR: Failed to clean the workspace 08:59:27 java.io.IOException: Unable to delete C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management - files in dir: [C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management\pom.properties, C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management\pom.xml] 08:59:27 at hudson.Util.deleteFile(Util.java:238) 08:59:27 at hudson.Util.deleteRecursive(Util.java:289) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200) 08:59:27 at hudson.Util.deleteRecursive(Util.java:280) 08:59:27 at hudson.FilePath$11.invoke(FilePath.java:910) 08:59:27 at hudson.FilePath$11.invoke(FilePath.java:908) 08:59:27 at hudson.FilePath.act(FilePath.java:842) 08:59:27 at hudson.FilePath.act(FilePath.java:824) 08:59:27 at hudson.FilePath.deleteRecursive(FilePath.java:908) 08:59:27 at hudson.plugins.git.GitAPI.clone(GitAPI.java:239)
[JIRA] (JENKINS-15237) Dependent Maven Jobs ignore version-number
Julien Carsique commented on JENKINS-15237 Dependent Maven Jobs ignore version-number Given the number of jobs we have, the issue is critical/blocker for us. See http://qa.nuxeo.org/jenkins/job/nuxeo-core-master/ The strange thing is the dependency between projects which is reported when clicking on a fingerprint is right: effective relationship: http://qa.nuxeo.org/jenkins/projectRelationship?lhs=nuxeo-core-masterrhs=nuxeo-services-master no relationship: http://qa.nuxeo.org/jenkins/projectRelationship?lhs=nuxeo-core-masterrhs=nuxeo-services-5.6.0 But, given the above sample, nuxeo-services-5.6.0 which has no dependency relation with nuxeo-core-master is badly triggered anyway. 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-15237) Dependent Maven Jobs ignore version-number
Julien Carsique edited a comment on JENKINS-15237 Dependent Maven Jobs ignore version-number Given the number of jobs we have, the issue is critical/blocker for us. See http://qa.nuxeo.org/jenkins/job/nuxeo-core-master/462 The strange thing is the dependency between projects which is reported when clicking on a fingerprint is right: effective relationship: http://qa.nuxeo.org/jenkins/projectRelationship?lhs=nuxeo-core-masterrhs=nuxeo-services-master no relationship: http://qa.nuxeo.org/jenkins/projectRelationship?lhs=nuxeo-core-masterrhs=nuxeo-services-5.6.0 But, given the above sample, nuxeo-services-5.6.0 which has no dependency relation with nuxeo-core-master is badly triggered anyway. 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-15266) Reduce SCM Sync logs
Julien Carsique created JENKINS-15266 Reduce SCM Sync logs Issue Type: Improvement Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 21/Sep/12 9:50 AM Description: There are too much logs. The following should be at DEBUG level, not INFO: Sep 21, 2012 11:46:59 AM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness processCommitsQueue INFO: Empty changeset to commit (no changes found on files) = commit skipped ! Sep 21, 2012 11:46:59 AM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness processCommitsQueue INFO: Processing commit : Commit hudson.plugins.scm_sync_configuration.model.Commit@f8fec07 : Author : SYSTEM Comment : Job [org.nuxeo.ecm.platform:nuxeo-birt-reporting-web] configuration updated by SYSTEM Changeset : A jobs/addons_nuxeo-birt-5.6.0/modules/org.nuxeo.ecm.platform$nuxeo-birt-reporting-web/config.xml Project: Jenkins Priority: Minor Reporter: Julien Carsique 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-15266) Reduce SCM Sync logs
Julien Carsique commented on JENKINS-15266 Reduce SCM Sync logs Usage statistics on half of a day: $ grep "Queuing commit" tomcat/logs/catalina.2012-09-21.log |wc -l 1666 $ grep "Processing commit" tomcat/logs/catalina.2012-09-21.log |wc -l 8525159 $ grep "Empty changeset to commit" tomcat/logs/catalina.2012-09-21.log |wc -l 8860655 $ grep "pushed to SCM" tomcat/logs/catalina.2012-09-21.log |wc -l 86 Reducing those logs to level DEBUG. 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-15266) Reduce SCM Sync logs
Julien Carsique assigned JENKINS-15266 to Julien Carsique Reduce SCM Sync logs Change By: Julien Carsique (21/Sep/12 10:22 AM) Assignee: FrédéricCamblor JulienCarsique 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-15266) Reduce SCM Sync logs
Julien Carsique commented on JENKINS-15266 Reduce SCM Sync logs https://github.com/jenkinsci/scm-sync-configuration-plugin/pull/7 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-14568) Improve commit messages from SCM Sync Configuration
Julien Carsique commented on JENKINS-14568 Improve commit messages from SCM Sync Configuration Confirmed: this only happens on SYSTEM modifications. 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
