[JIRA] (JENKINS-61408) Git executable is randomly set to empty string
Title: Message Title Stephane Odul commented on JENKINS-61408 Re: Git executable is randomly set to empty string We have some additional data about the issue. The empty string is because our git installer did not have a fallback value and so the git command ended up being null. The root cause is `Failed to get git executable` which is probably returned by the installer but we have no information as to why it is failing. In our case the installer is a just a shell script that writes an other shell script which becomes a wrapper for the git commands so that we can have smarter retry logic and better tuned ref specs than possible with the plugin. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.205062.1583793463000.8793.1586475060264%40Atlassian.JIRA.
[JIRA] (JENKINS-42668) Tests Results Analyser Loading Time
Title: Message Title Stephane Odul commented on JENKINS-42668 Re: Tests Results Analyser Loading Time We have several thousand tests and suffer from the very long analysis. We mitigated that by configuring the plugin to only read the last 25 runs and that helps a lot but also is very limiting since we can't get a good idea of what are the top 10 flaky tests over a certain period of time, just the last few hours in our case. I understand that this is caused by jenkins doing everything in XML and but I think the plugin could cache the data it has read from previous runs so that it can be a lot more efficient if the same report is requested twice or if most of the runs have been analyzed previously. A workaround we are considering is to have a post processing pipeline that will collect the test results and recreate them with only the failing tests as a trick to have very small test reports to analyze. This post job would be used to get a more useful report. If we can do this trickery, certainly the plugin can do this internally. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.179619.1489154689000.152.1585186560454%40Atlassian.JIRA.
[JIRA] (JENKINS-61408) Git executable is randomly set to empty string
Title: Message Title
Stephane Odul commented on JENKINS-61408
Re: Git executable is randomly set to empty string
Under Global Tool Configuration replace the Default Git installation with a custom one that uses a shell script. In our case we have 2 installers with filters:
master: the script is just `true` and Tool Home is `/usr/bin/git`
!master: the script is installing a simple shell wrapper to perform retry logic when the git commands fails due to transient network or server side glitches. The Tool Home is the path to the wrapper.
We use the GitHub Organization Plugin to scan our repos and trigger our CI pipelines, and we use the Kubernetes plugin to launch ephemeral workers for each stage. The kubernetes plugin is configured with a default 'jnlp' pod definition which is nothing more that the default pod definition that comes with the kubernetes plugin. The Jenkinsfile has parallel stages, it does not matter what the stages do. Very randomly, and infrequently, with no apparent cause one of the stages will get an empty git executable name with the stack trace provided in the description. Sample Jenkinsfile:
pipeline {
agent none
options {
ansiColor('xterm')
timestamps ()
buildDiscarder(logRotator(daysToKeepStr: '30'))
timeout(time: 5, unit: 'MINUTES')
}
stages {
stage('Tests') {
parallel {
stage('sleep 1') {
agent { kubernetes { label 'jnlp' } }
steps { sh 'sleep 1' }
}
stage('sleep 2') {
agent { kubernetes { label 'jnlp' } }
steps { sh 'sleep 2' }
}
stage('sleep 3') {
agent { kubernetes { label 'jnlp' } }
steps { sh 'sleep 3' }
}
stage('sleep 4') {
agent { kubernetes { label 'jnlp' } }
steps { sh 'sleep 4' }
}
stage('sleep 5') {
agent { kubernetes { label 'jnlp' } }
steps { sh 'sleep 5' }
}
}
}
}
post { always { chuckNorris() } }
}
Add Comment
[JIRA] (JENKINS-61408) Git executable is randomly set to empty string
Title: Message Title
Stephane Odul updated an issue
Jenkins / JENKINS-61408
Git executable is randomly set to empty string
Change By:
Stephane Odul
Once in a while, at least several times a week, the name of the Git executable ends up being unset and the Git plugin calls ` init` (whitespace) instead of `git init`.We use a custom installer for git and it works and install just fine and even with jobs with multiple parallel stages, only one stage hits the bug, randomly. So configuration on our side is just fine but we suspect that there is a bug in the codebase where the variable holding the git executable name can get invalidated, at the stage level. {noformat} [2020-03-04T19:28:38.877Z] Failed to get git executable [2020-03-04T19:28: 38.877Z] Failed to get git executable[2020-03-04T19:28: 42.682Z] using credential x-github-rw [2020-03-04T19:28:42.691Z] Cloning the remote Git repository [2020-03-04T19:28:42.691Z] Using shallow clone with depth 500 [2020-03-04T19:28:42.691Z] Avoid fetching tags [2020-03-04T19:28:42.691Z] Honoring refspec on initial clone [2020-03-04T19:28:42.933Z] ERROR: Error cloning remote repo 'origin' [2020-03-04T19:28:42.933Z] hudson.plugins.git.GitException: Could not init /home/jenkins/agent/workspace/GitHub__master [2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:989) [2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:747) [2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161) [2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154) [2020-03-04T19:28:42.933Z] at hudson.remoting.UserRequest.perform(UserRequest.java:211) [2020-03-04T19:28:42.934Z] at hudson.remoting.UserRequest.perform(UserRequest.java:54) [2020-03-04T19:28:42.934Z] at hudson.remoting.Request$2.run(Request.java:369) [2020-03-04T19:28:42.934Z] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) [2020-03-04T19:28:42.934Z] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [2020-03-04T19:28:42.934Z] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [2020-03-04T19:28:42.934Z] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [2020-03-04T19:28:42.934Z] at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:97) [2020-03-04T19:28:42.934Z] at java.lang.Thread.run(Thread.java:748) [2020-03-04T19:28:42.934Z] Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from ip-xx-xx-xx-xx.us-west-2.compute.internal/xx.xx.xx.xx:40980 [2020-03-04T19:28:42.934Z] at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) [2020-03-04T19:28:42.934Z] at
[JIRA] (JENKINS-61408) Git executable is randomly set to empty string
Title: Message Title
Stephane Odul updated an issue
Jenkins / JENKINS-61408
Git executable is randomly set to empty string
Change By:
Stephane Odul
Once in a while, at least several times a week, the name of the Git executable ends up being unset and the Git plugin calls ` init` (whitespace) instead of `git init`.We use a custom installer for git and it works and install just fine and even with jobs with multiple parallel stages, only one stage hits the bug, randomly. So configuration on our side is just fine but we suspect that there is a bug in the codebase where the variable holding the git executable name can get invalidated, at the stage level. {noformat} [2020-03-04T19:28:38.877Z] Failed to get git executable[2020-03-04T19:28:38.877Z] Failed to get git executable[2020-03-04T19:28:42.682Z] using credential x-github-rw[2020-03-04T19:28:42.691Z] Cloning the remote Git repository[2020-03-04T19:28:42.691Z] Using shallow clone with depth 500[2020-03-04T19:28:42.691Z] Avoid fetching tags[2020-03-04T19:28:42.691Z] Honoring refspec on initial clone[2020-03-04T19:28:42.933Z] ERROR: Error cloning remote repo 'origin'[2020-03-04T19:28:42.933Z] hudson.plugins.git.GitException: Could not init /home/jenkins/agent/workspace/GitHub__master[2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:989)[2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:747)[2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)[2020-03-04T19:28:42.933Z] at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)[2020-03-04T19:28:42.933Z] at hudson.remoting.UserRequest.perform(UserRequest.java:211)[2020-03-04T19:28:42.934Z] at hudson.remoting.UserRequest.perform(UserRequest.java:54)[2020-03-04T19:28:42.934Z] at hudson.remoting.Request$2.run(Request.java:369)[2020-03-04T19:28:42.934Z] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)[2020-03-04T19:28:42.934Z] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[2020-03-04T19:28:42.934Z] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[2020-03-04T19:28:42.934Z] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[2020-03-04T19:28:42.934Z] at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:97)[2020-03-04T19:28:42.934Z] at java.lang.Thread.run(Thread.java:748)[2020-03-04T19:28:42.934Z] Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from ip-xx-xx-xx-xx.us-west-2.compute.internal/xx.xx.xx.xx:40980[2020-03-04T19:28:42.934Z] at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)[2020-03-04T19:28:42.934Z] at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)[2020-03-04T19:28:42.934Z] at
[JIRA] (JENKINS-61408) Git executable is randomly set to empty string
Title: Message Title Stephane Odul created an issue Jenkins / JENKINS-61408 Git executable is randomly set to empty string Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2020-03-09 22:37 Environment: Jenkins 2.204.5 Git Plugin 4.1.1 Priority: Major Reporter: Stephane Odul Once in a while, at least several times a week, the name of the Git executable ends up being unset and the Git plugin calls ` init` (whitespace) instead of `git init`. We use a custom installer for git and it works and install just fine and even with jobs with multiple parallel stages, only one stage hits the bug, randomly. So configuration on our side is just fine but we suspect that there is a bug in the codebase where the variable holding the git executable name can get invalidated, at the stage level. [2020-03-04T19:28:38.877Z] Failed to get git executable[2020-03-04T19:28:38.877Z] Failed to get git executable[2020-03-04T19:28:42.682Z] using credential x-github-rw[2020-03-04T19:28:42.691Z] Cloning the remote Git repository[2020-03-04T19:28:42.691Z] Using shallow clone with depth 500[2020-03-04T19:28:42.691Z] Avoid fetching tags[2020-03-04T19:28:42.691Z] Honoring refspec on initial clone[2020-03-04T19:28:42.933Z] ERROR: Error cloning remote repo 'origin'[2020-03-04T19:28:42.933Z] hudson.plugins.git.GitException: Could not init /home/jenkins/agent/workspace/GitHub__master[2020-03-04T19:28:42.933Z] at
[JIRA] (JENKINS-61187) Option to create ref-spec to target branch when cloning
Title: Message Title Stephane Odul commented on JENKINS-61187 Re: Option to create ref-spec to target branch when cloning Sorry for not replying sooner, unfortunately were not able to try the given example yet due to more pressing issues on our side. We actually extended our Git wrapper to massage more of the git command, add retry logic and handle adding a depth when performing pull request jobs. We run into a bug where the value of the git command ends up being an empty string in one of several stages. This is random and rare and only when we have the custom installer configured. Once we have more time to investigate we will file additional reports for these bugs. Thank you for your help Mark Waite Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204731.1582328137000.749.1583512500194%40Atlassian.JIRA.
[JIRA] (JENKINS-61187) Option to create ref-spec to target branch when cloning
Title: Message Title Stephane Odul commented on JENKINS-61187 Re: Option to create ref-spec to target branch when cloning Mark Waite Unfortunately the multi branch pipelines are not a good substitute for the use case we need since they pretty much create a separate 'job' per branch, which in turn is causing scaling issues on the master with git repos that have hundreds of branches, even if we filter the branches. They are definitely not ideal for manually triggered jobs with input parameters from users. We do use them for our CI and Pull Requests workload, but not for the other types of jobs we use for various other tasks. Can you clarify how users can narrow the selection during the checkout command? We tried to set the ref-spec to +refs/heads/$BRANCH:refs/remotes/origin/$BRANCH but variables do not get expanded (there is a separate Jira for this) and that variable usually starts with origin/ which would make crafting the refspec a problem anyways. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204731.1582328137000.4791.1582402860173%40Atlassian.JIRA.
[JIRA] (JENKINS-61187) Option to create ref-spec to target branch when cloning
Title: Message Title Stephane Odul updated an issue Jenkins / JENKINS-61187 Option to create ref-spec to target branch when cloning Change By: Stephane Odul Summary: Option to create ref-spec to target branch when cloning Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204731.1582328137000.4670.1582329000401%40Atlassian.JIRA.
[JIRA] (JENKINS-61187) Option to ref-spec to target branch when cloning
Title: Message Title Stephane Odul created an issue Jenkins / JENKINS-61187 Option to ref-spec to target branch when cloning Issue Type: Improvement Assignee: Mark Waite Components: git-plugin Created: 2020-02-21 23:35 Environment: Jenkins 2.204.2 Git Plugin 4.1.1 Priority: Major Reporter: Stephane Odul We use the Kubernetes plugin to run Jenkins which means that every stage in our pipelines will always perform a full clone. Unfortunately this mean that the current behavior is to fetch all the branches which uses a lot more bandwidth and RAM than we need. We can can manually set the ref-spec to the target branch if the job will only run against a specific branch, but we have many pipelines that are allowed to run against any branch, in which case the ref-spec need to be left to default. We've had many pipeline failures caused by the git process running out of memory, or by the git server timing out. To work around these issue we have a shell script that wraps the git cli to: retry the commands 5 times, with backoff logic so stages won't fail due to a network/server glitch while fetching. detect if $BRANCH is set (GIT_BRANCH is not exposed here) and if the wildcard ref-spec is set massage the git fetch command to only fetch the targeted branch. This approach has lowered out git checkout times by 3x, the number of objects by 10x and the amount of data fetched from the git server by over 10x. It would be great to add theses 2 improvements directly into the git plugin so that others can benefit from this. We do know about the option to
[JIRA] (JENKINS-61072) Kubernetes declarative pipeline does not merge initContainer sections
Title: Message Title
Stephane Odul updated an issue
Jenkins / JENKINS-61072
Kubernetes declarative pipeline does not merge initContainer sections
Change By:
Stephane Odul
We use declarative pipelines with ` {{ yamlMergeStrategy merge() ` }} and a yaml entry. Some of the YAMLs have an `initContainers` {{initContainer}} section that is preserved when we do not set the merge strategy but get dropped from the final yaml when we do set the strategy to ` {{ merge() ` }} .[https://kubernetes.io/docs/concepts/workloads/pods/init-containers/] For reference the {{merge()}} option was added to the declarative pipeline in https://github.com/jenkinsci/kubernetes-plugin/pull/638
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on
[JIRA] (JENKINS-61072) Kubernetes declarative pipeline does not merge initContainer sections
Title: Message Title Stephane Odul created an issue Jenkins / JENKINS-61072 Kubernetes declarative pipeline does not merge initContainer sections Issue Type: Bug Assignee: Unassigned Components: kubernetes-plugin Created: 2020-02-13 01:47 Environment: kubernetes:1.23.1 Priority: Major Reporter: Stephane Odul We use declarative pipelines with `yamlMergeStrategy merge()` and a yaml entry. Some of the YAMLs have an `initContainers` section that is preserved when we do not set the merge strategy but get dropped from the final yaml when we do set the strategy to `merge()`. https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ Add Comment
[JIRA] [maven-plugin] (JENKINS-24788) Cannot run program /bin/java on maven 3 projects
Stephane Odul commented on JENKINS-24788 Cannot run program /bin/java on maven 3 projects Issue is still present with 1.584. 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-24788) Cannot run program /bin/java on maven 3 projects
Stephane Odul updated JENKINS-24788 Cannot run program /bin/java on maven 3 projects Change By: Stephane Odul (24/Sep/14 9:20 PM) Environment: 1.580,Ubuntu12.04LTS64 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-24788) Cannot run program /bin/java on maven 3 projects
Stephane Odul created JENKINS-24788 Cannot run program /bin/java on maven 3 projects Issue Type: Bug Assignee: Unassigned Components: maven Created: 22/Sep/14 6:22 AM Description: We've had this issue for a while, mostly after a slave is started where the maven command insist on using /bin/java. We do not have a /bin/java since we want to control the version of Java on a per job basis, so adding it is not an option. 00:00:06.627 Parsing POMs 00:00:07.322 maven3-agent.jar already up to date 00:00:07.331 maven3-interceptor.jar already up to date 00:00:07.341 maven3-interceptor-commons.jar already up to date 00:00:07.347 [build-shnproxy-trunk] $ /bin/java -Xmx6000m -XX:MaxPermSize=2000m -cp /shn/builder/maven3-agent.jar:/shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5 /shn/builder/slave.jar /shn/builder/maven3-interceptor.jar /shn/builder/maven3-interceptor-commons.jar 33037 00:00:07.353 ERROR: Failed to parse POMs 00:00:07.353 java.io.IOException: Cannot run program "/bin/java" (in directory "/shn/builder/workspace/build-shnproxy-trunk"): java.io.IOException: error=2, No such file or directory 00:00:07.353 at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) 00:00:07.353 at hudson.Proc$LocalProc.init(Proc.java:244) 00:00:07.353 at hudson.Proc$LocalProc.init(Proc.java:216) 00:00:07.353 at hudson.Launcher$LocalLauncher.launch(Launcher.java:802) 00:00:07.353 at hudson.Launcher$ProcStarter.start(Launcher.java:380) 00:00:07.353 at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1135) 00:00:07.353 at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1100) 00:00:07.353 at hudson.remoting.UserRequest.perform(UserRequest.java:118) 00:00:07.353 at hudson.remoting.UserRequest.perform(UserRequest.java:48) 00:00:07.353 at hudson.remoting.Request$2.run(Request.java:328) 00:00:07.353 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 00:00:07.353 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 00:00:07.353 at java.util.concurrent.FutureTask.run(FutureTask.java:138) 00:00:07.353 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) 00:00:07.353 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) 00:00:07.353 at java.lang.Thread.run(Thread.java:662) 00:00:07.353 Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory 00:00:07.353 at java.lang.UNIXProcess.init(UNIXProcess.java:148) 00:00:07.353 at java.lang.ProcessImpl.start(ProcessImpl.java:65) 00:00:07.353 at java.lang.ProcessBuilder.start(ProcessBuilder.java:453) 00:00:07.353 ... 15 more Usually after a few failed builds the slave gets the correct version of java and works: Parsing POMs maven3-agent.jar already up to date maven3-interceptor.jar already up to date maven3-interceptor-commons.jar already up to date [build-shnproxy-trunk] $ /shn/builder/tools/hudson.model.JDK/JDK7/jdk1.7.0_51/bin/java -Xmx6000m -XX:MaxPermSize=2000m -cp /shn/builder/maven3-agent.jar:/shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5 /shn/builder/slave.jar /shn/builder/maven3-interceptor.jar /shn/builder/maven3-interceptor-commons.jar 58912 ===[JENKINS REMOTING CAPACITY]===���channel started This time it has been stuck for 2 jobs for the past 2 days, with no end in sight. I can't figure out why it keeps on pointing to /bin/java Project: Jenkins Priority: Major Reporter: Stephane Odul
[JIRA] [maven] (JENKINS-24788) Cannot run program /bin/java on maven 3 projects
Stephane Odul updated JENKINS-24788 Cannot run program /bin/java on maven 3 projects Change By: Stephane Odul (22/Sep/14 7:20 PM) Attachment: jdk-installations.png Attachment: job-config-jdk.png 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-24788) Cannot run program /bin/java on maven 3 projects
Stephane Odul commented on JENKINS-24788 Cannot run program /bin/java on maven 3 projects I specify the Jav aper job with the JDK setting in the config page (see job-config-jdk.png attachment), and each JDK is either downloaded from our artifactory repo, from Sun/Oracle, or simply pointed to the one managed with the OS by Salt (like Puppet or Chef), see jdk-installations.png. 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-24788) Cannot run program /bin/java on maven 3 projects
Stephane Odul edited a comment on JENKINS-24788 Cannot run program /bin/java on maven 3 projects I specify the Java install to use per job with the JDK setting in the config page (see job-config-jdk.png attachment), and each JDK is either downloaded from our artifactory repo, from Sun/Oracle, or simply pointed to the one managed with the OS by Salt (like Puppet or Chef), see jdk-installations.png. 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] [javanet] (JENKINS-15288) JAVA_HOME env variable not populating path to JDK installation
Stephane Odul commented on JENKINS-15288 JAVA_HOME env variable not populating path to JDK installation I'm getting this quite often on maven builds but not consistently. Eventually the Slave will gets its brain back together and get the jvm that it auto install, but it cause a bit of confusion and complaints from our developers. 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-21903) Not all maven downstream jobs get triggered
Stephane Odul commented on JENKINS-21903 Not all maven downstream jobs get triggered Also present in 1.558 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-21903) Not all maven downstream jobs get triggered
Stephane Odul commented on JENKINS-21903 Not all maven downstream jobs get triggered Still present in 1.553. I have a job with 15 downstream projects listed and only 5 are actually triggered. 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] [xvnc] (JENKINS-22105) [xvnc] Client is not authorized to connect to Server
Stephane Odul commented on JENKINS-22105 [xvnc] Client is not authorized to connect to Server Yes: TightVNC Server version 1.3.9 The OS is Ubuntu 12.04 LTS AMD64 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-21903) Not all maven downstream jobs get triggered
Stephane Odul created JENKINS-21903 Not all maven downstream jobs get triggered Issue Type: Bug Assignee: olamy Components: maven, maven-dependency-update-trigger Created: 20/Feb/14 7:56 PM Description: We have a maven job Foo with 10 downstream dependencies. In the Job page all the dependencies are noted clearly as well as on the the actual build page. Hower some of the downstream Jobs show with "(none)" instead of their build number and the log of the Foo build shows the "Triggering a new build of " lines, but only for 7 out of the 10 that should be triggered. Jenkins clearly knows about the SNAPSHOT dependency and shows the downstream relationship correctly, yet it 'forgets' to trigger some of the jobs. Confirmed with 1.550 and 1.551. Project: Jenkins Priority: Major Reporter: Stephane Odul 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-9258) Remember me on this computer, still getting asked to log in after a few hours
Stephane Odul commented on JENKINS-9258 Remember me on this computer, still getting asked to log in after a few hours John, the issue with 1.494 is different and tracked in JENKINS-16278. 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-9258) Remember me on this computer, still getting asked to log in after a few hours
Stephane Odul commented on JENKINS-9258 Remember me on this computer, still getting asked to log in after a few hours We run our instance as a simple setup on a ubuntu 10.04 machine. Runs on port 8080 but forwarded from port 80. There is only one url that we use including the port (default, since we use 80 in practice). Apparently the trick would be to update web.xml to include this right after the description (or later): session-config session-timeout1440/session-timeout /session-config This would tell WinStone (or Tomcat) to have a session expiration of 24h (24*60=1440). The problem is that it would require to extract jenkins.war, patch web.xml and re-zip jenkins.war. Not very automated to get the autoupdates. I do not see a ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE in my browser, I do see a JSESSIONID.12345abc cookie though. 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-9258) Remember me on this computer, still getting asked to log in after a few hours
Stephane Odul edited a comment on JENKINS-9258 Remember me on this computer, still getting asked to log in after a few hours We run our instance as a simple setup on a ubuntu 10.04 machine. Runs on port 8080 but forwarded from port 80. There is only one url that we use including the port (default, since we use 80 in practice). Apparently the trick would be to update web.xml to include this right after the description (or later): session-config session-timeout1440/session-timeout /session-config This would tell WinStone (or Tomcat) to have a session expiration of 24h (24*60=1440). The problem is that it would require to extract jenkins.war, patch web.xml and re-zip jenkins.war. Not very automated to get the autoupdates. ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE is set when 'Remember Me' is checked, it seems valid and expire after 2 weeks. 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-14715) Unable to add new Trigger/call builds on other projects build step
Stephane Odul
created JENKINS-14715
Unable to add new Trigger/call builds on other projects build step
Issue Type:
Bug
Assignee:
huybrechts
Components:
parameterized-trigger, parameters
Created:
07/Aug/12 5:51 PM
Description:
This has started happening on our Jenkins instance a few weeks ago. We are running Jenkins 1.476 and Parameterized Trigger 2.15.
When I first try too add a trigger, the UI does not get any options, the second attempt give me one with invalid settings (non blocking should not show the Failure options).
When I try to save I get these exceptions in the master log.
Caused by: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":{"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"sandbox-sleep1m","unstableThreshold":"UNSTABLE"},"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
at hudson.model.Descriptor.newInstance(Descriptor.java:575)
at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
at hudson.util.DescribableList.rebuildHetero(DescribableList.java:203)
at hudson.model.Project.submit(Project.java:202)
at hudson.model.Job.doConfigSubmit(Job.java:990)
at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:699)
... 67 more
Existing jobs seems to run as expected, but we cannot update/add configuration that requires this feature.
Project:
Jenkins
Priority:
Major
Reporter:
Stephane Odul
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-14715) Unable to add new Trigger/call builds on other projects build step
Stephane Odul updated JENKINS-14715 Unable to add new Trigger/call builds on other projects build step Added screenshot showing the unstable behavior when adding the build parameter to a job. Change By: Stephane Odul (07/Aug/12 6:35 PM) Attachment: screenshot-1.jpg 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
