[JIRA] (JENKINS-56061) Containers created in templates via Raw Yaml are completely ignored
Title: Message Title
Tom Larrow created an issue
Jenkins / JENKINS-56061
Containers created in templates via Raw Yaml are completely ignored
Issue Type:
Bug
Assignee:
Carlos Sanchez
Components:
kubernetes-plugin
Created:
2019-02-08 20:11
Environment:
Jenkins 2.162 Kubernetes Plugin 1.14.3
Priority:
Minor
Reporter:
Tom Larrow
Trying to make the kubernetes plugin assign proper volumes to each container in the pod and running into some difficulties: Building with no template, and passing in the following .yaml to the kubernetes plugin works: from Jenkinsfile:
agent {
kubernetes {
cloud 'openshift'
label 'golang-build'
yamlFile 'kubernetesPod.yaml'
}
}
kubernetesPod.yaml:
spec:
containers:
- name: jnlp
image: 'jenkins/jnlp-slave:latest'
volumeMounts:
- name: gitconfig
mountPath: /home/jenkins/.git/.gitconfig
subPath: .gitconfig
- name: docker
image: docker:1.13.1
command: ['cat']
tty: true
volumeMounts:
- name: dockersock
mountPath: /var/run/docker.sock
- mountPath: /root/.docker/config.json
subPath: config.json
name: jenkins-creds
- name: golang
image: golang:1-alpine
command: ['cat']
tty: true
volumes:
- name: dockersock
hostPath:
[JIRA] (JENKINS-42855) BUILD_ID not sequential for Pipeline jobs when hp-application-automation-tools is installed
Title: Message Title Tom Larrow commented on JENKINS-42855 Re: BUILD_ID not sequential for Pipeline jobs when hp-application-automation-tools is installed Thanks for tracking that down and getting it correctly assigned. Really appreciate your help. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42855) BUILD_ID not sequential
Title: Message Title Tom Larrow commented on JENKINS-42855 Re: BUILD_ID not sequential plugins.txt added with that output Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42855) BUILD_ID not sequential
Title: Message Title Tom Larrow updated an issue Jenkins / JENKINS-42855 BUILD_ID not sequential Change By: Tom Larrow Attachment: plugins.txt Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42855) BUILD_ID not sequential
Title: Message Title Tom Larrow commented on JENKINS-42855 Re: BUILD_ID not sequential Added an xml report of all plugins installed. We had been delaying updating packages while we pushed through a major release, so there were a large number of plugins updated this morning. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42855) BUILD_ID not sequential
Title: Message Title Tom Larrow updated an issue Jenkins / JENKINS-42855 BUILD_ID not sequential Change By: Tom Larrow Attachment: plugins.xml Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42855) BUILD_ID not sequential
Title: Message Title Tom Larrow commented on JENKINS-42855 Re: BUILD_ID not sequential Yes, I put together a quick scripted job and it is performing the same way. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42855) BUILD_ID not sequential
Title: Message Title Tom Larrow commented on JENKINS-42855 Re: BUILD_ID not sequential Any other plugins you need versions of? Is there an easy way to generate a report of what I have installed? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42855) BUILD_ID not sequential
Title: Message Title
Tom Larrow created an issue
Jenkins / JENKINS-42855
BUILD_ID not sequential
Issue Type:
Bug
Assignee:
Andrew Bayer
Attachments:
jenkins count by 2.png, pasted_image_at_2017_03_16_12_56_pm_360.png
Components:
pipeline-model-definition-plugin
Created:
2017/Mar/16 6:22 PM
Environment:
Jenkins 2.50 running on RHEL 7 linux Pipeline 2.5 Pipeline API 2.12 Pipeline Declarative Agent API 1.1.1 Pipeline Declarative Extension Points Api 1.1.1 Pipeline Groovy 2.29 Pipeline Job 2.10 Pipeline Model API 1.1.1 Pipeline Model Definition 1.1.1
Priority:
Minor
Reporter:
Tom Larrow
Most jobs have started incrementing their build numbers by 2. A few jobs have started counting by 3. I thought it may have been folder related as one of the jobs that was counting by 3 was a bit deeper in a folder, but in further testing, a test job was counting by 2 no matter if it was 5 folders deep, or in the root of Jenkins. Test job which is counting by 2 is built with this Jenkinsfile put directly in the editor in Jenkins so no SCM involved pipeline{ agent{ label 'master' } stages{ stage("test"){ steps{ echo "test" } } } } Testing a freestyle job which also just did an echo and everything was sequential
[JIRA] (JENKINS-40866) docker.inside() like syntax that keeps the workspace
Title: Message Title
Tom Larrow commented on JENKINS-40866
Re: docker.inside() like syntax that keeps the workspace
I agree with Patrick Wolf that if I had already written pipelines that expected a new workspace every time, I wouldn't want the default changed on me. I like the option of reuseNode being something I could set in the options, so I wouldn't need to specify it every time I used it. Just to make sure I was reading the code correctly, It looked like the vars would still be available to use in the stage agent definition. We don't do true docker in docker, rather if we have one docker container building another, we pass in the arg "-v /var/run/docker.sock:/var/run/docker.sock" in order to let the docker daemon inside the container control the host's docker and build sibling containers. Other than that, it looks good, and will save quite a bit of script{} blocks in my declarative pipeline code.
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-40866) docker.inside() like syntax that keeps the workspace
Title: Message Title
Tom Larrow edited a comment on JENKINS-40866
Re: docker.inside() like syntax that keeps the workspace
michaelneale that is generally it. I've actually been going back and forth a bit on this, and not fully sure what the right solution is.First a quick correction: "When using agent .. docker, should checkout scm always happen outside of docker? (so the image doesn't need to have git)?"The image doesn't need git to do the pull, it is doing the git clone/checkout just fine. I need it because I am trying to pull in the Git environment variables, to find the origin of the commit, and the hash so that I can bake that metadata into the docker image's metadata for tracking. If things like https://issues.jenkins-ci.org/browse/JENKINS-35230 and https://issues.jenkins-ci.org/browse/JENKINS-34455 were fixed, and I had access to that metadata from the pipeline, I wouldn't need to use the commands listed at https://jenkins.io/doc/pipeline/examples/#gitcommit which use git locally to get those variables.As far as my initial comment. Everything works in declarative pipeline if I do what was suggested, put the pipeline on the agent: pipeline {agent label:'swarm'and then use a script block, with docker.inside() in it.I have just been trying to avoid script blocks as much as possible to make the pipelines as usable by others with little pipeline experience as possible.As far as what makes sense, guess the easiest would be something along the lines of being able to do a stage with some nomenclature like this:stage{ agent: same, docker: 'node'and that would keep things on the same agent (syntax sort of like 'none') but inside that docker image.That would of course force me to give up palatalization parallelizatoin where different parallel steps use different docker build environments, as the docker container would be tied to a stage, and stages can't be parallelized. But in my mental debates that is something that could be given up to greatly simplify the pipeline syntax.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40866) docker.inside() like syntax that keeps the workspace
Title: Message Title
Tom Larrow edited a comment on JENKINS-40866
Re: docker.inside() like syntax that keeps the workspace
michaelneale that is generally it. I've actually been going back and forth a bit on this, and not fully sure what the right solution is.First a quick correction: "When using agent .. docker, should checkout scm always happen outside of docker? (so the image doesn't need to have git)?"The image doesn't need git to do the pull, it is doing the git clone/checkout just fine. I need it because I am trying to pull in the Git environment variables, to find the origin of the commit, and the hash so that I can bake that metadata into the docker image's metadata for tracking. If things like https://issues.jenkins-ci.org/browse/JENKINS-35230 and https://issues.jenkins-ci.org/browse/JENKINS-34455 were fixed, and I had access to that metadata from the pipeline, I wouldn't need to use the commands listed at https://jenkins.io/doc/pipeline/examples/#gitcommit which use git locally to get those variables.As far as my initial comment. Everything works in declarative pipeline if I do what was suggested, put the pipeline on the agent: pipeline {agent label:'swarm'and then use a script block, with docker.inside() in it.I have just been trying to avoid script blocks as much as possible to make the pipelines as usable by others with little pipeline experience as possible.As far as what makes sense, guess the easiest would be something along the lines of being able to do a stage with some nomenclature like this:stage{ agent: same, docker: 'node'and that would keep things on the same agent (syntax sort of like 'none') but inside that docker image.That would of course force me to give up parallelizatoin parallelization where different parallel steps use different docker build environments, as the docker container would be tied to a stage, and stages can't be parallelized. But in my mental debates that is something that could be given up to greatly simplify the pipeline syntax.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40866) docker.inside() like syntax that keeps the workspace
Title: Message Title
Tom Larrow commented on JENKINS-40866
Re: docker.inside() like syntax that keeps the workspace
michaelneale that is generally it. I've actually been going back and forth a bit on this, and not fully sure what the right solution is. First a quick correction: "When using agent .. docker, should checkout scm always happen outside of docker? (so the image doesn't need to have git)?" The image doesn't need git to do the pull, it is doing the git clone/checkout just fine. I need it because I am trying to pull in the Git environment variables, to find the origin of the commit, and the hash so that I can bake that metadata into the docker image's metadata for tracking. If things like https://issues.jenkins-ci.org/browse/JENKINS-35230 and https://issues.jenkins-ci.org/browse/JENKINS-34455 were fixed, and I had access to that metadata from the pipeline, I wouldn't need to use the commands listed at https://jenkins.io/doc/pipeline/examples/#gitcommit which use git locally to get those variables. As far as my initial comment. Everything works in declarative pipeline if I do what was suggested, put the pipeline on the agent: pipeline { agent label:'swarm' and then use a script block, with docker.inside() in it. I have just been trying to avoid script blocks as much as possible to make the pipelines as usable by others with little pipeline experience as possible. As far as what makes sense, guess the easiest would be something along the lines of being able to do a stage with some nomenclature like this: stage{ agent: same, docker: 'node' and that would keep things on the same agent (syntax sort of like 'none') but inside that docker image. That would of course force me to give up palatalization where different parallel steps use different docker build environments, as the docker container would be tied to a stage, and stages can't be parallelized. But in my mental debates that is something that could be given up to greatly simplify the pipeline syntax.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40866) docker.inside() like syntax that keeps the workspace
Title: Message Title
Tom Larrow created an issue
Jenkins / JENKINS-40866
docker.inside() like syntax that keeps the workspace
Issue Type:
Improvement
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2017/Jan/06 5:24 PM
Priority:
Minor
Reporter:
Tom Larrow
With the traditional pipeline we have been able to do a mixture of working with the Jenkins workspace and using docker.inside() to pull in docker containers which have additional build tools needed to do a build. Docker.inside() maps the jenkins workspace to docker volume, so that what happens inside the docker container can read from, and write to the jenkins workspace. Part of this is our build environment. The builds all run from slaves which run as docker containers inside Kubernetes. Those pods run privileged, so that they can reach the docker socket on the host to spin up "peer" docker containers when the docker.inside() commands are run. This is needed in order to run docker commands and to build new docker containers. So for instance a slave does a checkout scm. gathers information about the repository commit using git commands, then does docker.inside() to pull in a pre-configured docker image with all the necessary npm modules already installed. It runs the gulp tasks inside() the container which thanks to the way things are mapped, writes the gulp output back to the jenkins workpace. Then the inside() block closes, and the next steps of the pipeline do a docker build, and docker push to our registry. I initially tired doing this in declarative pipeline by using an agent statement at the top just inside the pipeline{ agent label:'swarm', docker:'our-registry/npm-build:latest' This initially failed because while the slave has git on it, git does not exist inside that npm-build image, so I couldn't use the git commands to determine the url and git commit hash I initially added git to that image, and that part worked, but then I realized I could go no further, since there was no way
[JIRA] (JENKINS-40721) Wrappers provided by plugins not working correctly
Title: Message Title
Tom Larrow updated an issue
Jenkins / JENKINS-40721
Wrappers provided by plugins not working correctly
Change By:
Tom Larrow
I was going through how to use wrappers in Declarative Pipeline https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Advanced looking how to use the timestamper plugin specifically. Initially I used the wrap() syntax around the classname, which provided this rather helpful error message {{ org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:WorkflowScript: 9: Invalid wrapper type 'wrap'. Valid wrapper types: [ansiColor, catchError, gitlabBuilds, gitlabCommitStatus, lock, node, podTemplate, retry, script, timeout, timestamps, waitUntil, withContext, withEnv, ws] @ line 9, column 9. wrap([$class: 'TimestamperBuildWrapper']) ^ }} So there it was, I just needed to use 'timestamps' and it should work, as declarative pipeline identified it as an available wrapper.Unfortunately when trying to do that, I received the following error {{ org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:WorkflowScript: 9: Expected a wrapper @ line 9, column 9. timestamps ^ }} To see if it was an issue with the timestamper plugin, I also tried it with ansiColor, which again showed above as an available wrapper {{ org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:WorkflowScript: 9: Expected a wrapper @ line 9, column 9. ansiColor ^ }} It seems Declarative pipeline is identifying them as available wrappers, but unable to use them as wrappers
Add Comment
[JIRA] (JENKINS-40721) Wrappers provided by plugins not working correctly
Title: Message Title
Tom Larrow created an issue
Jenkins / JENKINS-40721
Wrappers provided by plugins not working correctly
Issue Type:
Bug
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2016/Dec/29 5:09 PM
Priority:
Minor
Reporter:
Tom Larrow
I was going through how to use wrappers in Declarative Pipeline https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Advanced looking how to use the timestamper plugin specifically. Initially I used the wrap() syntax around the classname, which provided this rather helpful error message {{org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 9: Invalid wrapper type 'wrap'. Valid wrapper types: [ansiColor, catchError, gitlabBuilds, gitlabCommitStatus, lock, node, podTemplate, retry, script, timeout, timestamps, waitUntil, withContext, withEnv, ws] @ line 9, column 9. wrap([$class: 'TimestamperBuildWrapper']) ^}} So there it was, I just needed to use 'timestamps' and it should work, as declarative pipeline identified it as an available wrapper. Unfortunately when trying to do that, I received the following error {{org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 9: Expected a wrapper @ line 9, column 9. timestamps ^ }} To see if it was an issue with the timestamper plugin, I also tried it with ansiColor, which again showed above as an available wrapper {{org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 9: Expected a wrapper @ line 9, column 9. ansiColor ^}} It seems Declarative pipeline is identifying them as available wrappers, but unable to use them as wrappers
[JIRA] (JENKINS-36117) OpenShift Deployment Verification Timeout not working
Title: Message Title Tom Larrow commented on JENKINS-36117 Re: OpenShift Deployment Verification Timeout not working That worked, thank you. I assume it'll default to that value if a waitTime parameter isn't passed in. That kind of gives us the best of both worlds, the ability to set a sane default value, and allow a different project to override if necessary. Thanks for your quick help on this issue. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36117) OpenShift Deployment Verification Timeout not working
Title: Message Title Tom Larrow commented on JENKINS-36117 Re: OpenShift Deployment Verification Timeout not working Yes, I probably should have clarified, this is all being done with Pipeline groovy script. 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-36117) OpenShift Deployment Verification Timeout not working
Title: Message Title
Tom Larrow created an issue
Jenkins / JENKINS-36117
OpenShift Deployment Verification Timeout not working
Issue Type:
Bug
Assignee:
Gabe Montero
Components:
openshift-pipeline-plugin
Created:
2016/Jun/21 1:35 PM
Priority:
Minor
Reporter:
Tom Larrow
No matter the value set for OpenShift Deployment Verification in the Jenkins configuration, the timeout that the OpenShift Deployment Verification seems to be set at 60 seconds. We have tried increasing the value, but no matter what deployments will fail with the status [Running] if they take longer than 60 seconds. A recent update to our Openshift environment has caused deployments to regularly exceed 60 seconds, and we have had to counter the deployment verification timeout by wrapping the verification step in a retry(3){ } step just to increase the timeout from 1 minute to 3.
Add Comment
[JIRA] [email-ext-plugin] (JENKINS-33980) Document (List) Pipeline features of email-ext-plugin
Title: Message Title Tom Larrow commented on JENKINS-33980 Re: Document (List) Pipeline features of email-ext-plugin Tokens are the biggest thing, but they feed into templates. I'm trying to build an Enterprise version of Jenkins, and bringing jobs over from lots of teams had on their own Jenkins servers running under someone's desk somewhere. One of the big goals has been to use Pipeline, and build a DSL to standardize everything. Almost all of the jobs from the other teams are freestyle and most use email-ext and have built elaborate templates in the Email-ext Template plugin. There's nothing in https://jenkins.io/doc/pipeline/steps/email-ext/ which describes how to call a template. Since templates could have different messages, and many other components based on the trigger, this is what was causing me to ask how to "throw" a trigger to the Email-ext plugin in order to select a different portion of a template. Additionally, (and this may be something that is there I'm just not seeing how to do it with the documentation) how do we include the possible culprits in the emails? This is one of the best features of Email-ext, to include an ever larger and larger group of people in the notifications until the build gets fixed. I didn't know if it is something as simple as including $CULPRITS in the to field, or if there is something that needs to be in the groovy 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] [email-ext-plugin] (JENKINS-33980) Document (List) Pipeline features of email-ext-plugin
Title: Message Title Tom Larrow commented on JENKINS-33980 Re: Document (List) Pipeline features of email-ext-plugin Agreed, it seems like much of the email-ext functionality is not available with the pipeline. Templates, triggers, and many of the tokens seem to not work when called from a Pipeline script. Email-ext seems to have pretty good documentation overall, but none of it seems to apply to the limited subset of features available to pipeline. Better documentation and examples, and even some templates (if they are available in pipeline) would help us understand what is available, where the gaps exist in functionality available to pipeline, and let us know if there are things we can help contribute to bring the email-ext pipeline features up to the same level that freestyle projects have. 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.
