[JIRA] (JENKINS-54542) allow the `agent` block to be ignored
Title: Message Title
James Strachan created an issue
Jenkins / JENKINS-54542
allow the `agent` block to be ignored
Issue Type:
Task
Assignee:
Oleg Nenashev
Components:
jenkinsfile-runner
Created:
2018-11-08 14:50
Priority:
Minor
Reporter:
James Strachan
When using Jenkins X we have build packs with Jenkisnfiles using `agent` labels for pod templates and kubernetes plugins like this: e.g. our build packs use Jenkinsfiles like this: https://github.com/jenkins-x/draft-packs/blob/2.1/packs/maven/Jenkinsfile#L2 vs with
agent {
label "jenkins-maven"
}
for serverless jenkins we had to create a branch in the build pack like this: https://github.com/jenkins-x/draft-packs/blob/prow/packs/maven/Jenkinsfile#L2 using
agent any
It would be awesome to have a CLI argument or environment variable that basically ignores the `agent` setting! Then we won't need to have a separate set of build packs for serverless
[JIRA] (JENKINS-54427) support other containers
Title: Message Title
James Strachan created an issue
Jenkins / JENKINS-54427
support other containers
Issue Type:
Task
Assignee:
Oleg Nenashev
Components:
jenkinsfile-runner
Created:
2018-11-02 14:23
Priority:
Minor
Reporter:
James Strachan
When using jenkinsfile-runner inside Kubernetes such as with Prow/Knative Build in Jenkins X it would be awesome to be able to replicate the kubernetes-plugin style execution of commands in sidecars all from within the exact same pod. e.g.
sh "echo this runs in the same container as the jenkinsfile runner"
container("selenium") {
sh "echo this runs in the selenium container"
}
When using pure knative build steps this stuff all works already; but its not yet supported in a Jenkinsfile. I understand that the jenkinsfile runner is just 1 container that runs & isn't gonna be able to grok the sidecar containers - but thats fine - we can configure that stuff outside of the jenkisnfile + jenksinfile-runner - but it'd be nice to be able to execute commands in sidecar containers (e.g. via the shell command:
kubectl exec -it $HOSTNAME -c selenium -- echo "this runs in the selenium continaer"
[JIRA] (JENKINS-53767) Offer plugin management tooling
Title: Message Title James Strachan edited a comment on JENKINS-53767 Re: Offer plugin management tooling I'm a big fan of GitOps and using source code to define what version of jenkins core, dockerfile, plugins and their versions etc that folks wanna use. Then to upgrade a plugin/core its a Pull Request. It'd be nice to enumerate all the different ways folks configure jenkins core + plugins + versions via source code to generate/setup their Jenkins server. e.g. there's the classic Dockerfile + plugins.txt approach like this... [ https://github.com/garethjevans/jenkins-quickstart01/tree/master/jenkinsConfig/departmentFoo/teamA ] or there's Custom War Packager style:[https://github.com/garethjevans/jenkins-cwp-quickstart01/blob/master/packager-config.yml#L11]then there's CasC YAML too. I It shouldn ' d like a way t be too hard to use something like handle those 3 source code formats. Then we could create a plugin for updatebot [https://github.com/jenkins-x/updatebot/] to automate the generation of PRs for folks using GitOps to upgrade jenkins and/or plugins using either Evergreen, incrementals: [https://repo.jenkins-ci.org/incrementals/] or releases: [ https://repo.jenkins-ci.org/releases/ ] Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53767) Offer plugin management tooling
Title: Message Title James Strachan assigned an issue to James Strachan Jenkins / JENKINS-53767 Offer plugin management tooling Change By: James Strachan Assignee: James Strachan Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53767) Offer plugin management tooling
Title: Message Title James Strachan commented on JENKINS-53767 Re: Offer plugin management tooling I'm a big fan of GitOps and using source code to define what version of jenkins core, dockerfile, plugins and their versions etc that folks wanna use. Then to upgrade a plugin/core its a Pull Request. It'd be nice to enumerate all the different ways folks configure jenkins core + plugins + versions to generate/setup their Jenkins server. e.g. there's the classic Dockerfile + plugins.txt approach like this... https://github.com/garethjevans/jenkins-quickstart01/tree/master/jenkinsConfig/departmentFoo/teamA or there's Custom War Packager style: https://github.com/garethjevans/jenkins-cwp-quickstart01/blob/master/packager-config.yml#L11 then there's CasC YAML too. I'd like a way to use something like updatebot to automate the generation of PRs for folks using GitOps to upgrade jenkins and/or plugins using either Evergreen, incrementals: https://repo.jenkins-ci.org/incrementals/ or releases: https://repo.jenkins-ci.org/releases/ Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50459) 401 when trying to update the build status in gitea
Title: Message Title James Strachan commented on JENKINS-50459 Re: 401 when trying to update the build status in gitea Stephen Connolly I wonder in your tests was that a regular UserPasswordCredential being used under the covers? I'm wondering if this is an effect of using the kubernetes credentials provider plugin which creates the credentials and is only aware of the standard Credential implementation classes right now Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50459) 401 when trying to update the build status in gitea
Title: Message Title James Strachan edited a comment on JENKINS-50459 Re: 401 when trying to update the build status in gitea [~stephenconnolly] I wonder in your tests was that a regular UserPasswordCredential class being used under the covers? I'm wondering if this is an effect of using the kubernetes credentials provider plugin which creates the credentials and is only aware of the standard Credential implementation classes right now Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50459) 401 when trying to update the build status in gitea
Title: Message Title James Strachan commented on JENKINS-50459 Re: 401 when trying to update the build status in gitea Turns out it’s not related! Tried using a manually created regular username/password - plus a Gitea Personal Access Token credential- they all fail with a 401 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-50459) 401 when trying to update the build status in gitea
Title: Message Title James Strachan commented on JENKINS-50459 Re: 401 when trying to update the build status in gitea this could maybe be related to the kind of Credential it is and its format/data - we hit a similar issue with Bitbucket on Jenkins X: https://github.com/jenkins-x/jx/issues/665 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-50560) add some docs to the readme on what kinds of Secrets are supported
Title: Message Title James Strachan closed an issue as Fixed Jenkins / JENKINS-50560 add some docs to the readme on what kinds of Secrets are supported Change By: James Strachan Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50560) add some docs to the readme on what kinds of Secrets are supported
Title: Message Title James Strachan commented on JENKINS-50560 Re: add some docs to the readme on what kinds of Secrets are supported ditto to your first comment 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-50560) add some docs to the readme on what kinds of Secrets are supported
Title: Message Title James Strachan commented on JENKINS-50560 Re: add some docs to the readme on what kinds of Secrets are supported how about for now copy/pasting that into the README? 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-50560) add some docs to the readme on what kinds of Secrets are supported
Title: Message Title James Strachan created an issue Jenkins / JENKINS-50560 add some docs to the readme on what kinds of Secrets are supported Issue Type: Task Assignee: James Nord Components: kubernetes-credentials-provider-plugin Created: 2018-04-04 04:51 Priority: Minor Reporter: James Strachan would be nice to hack the README.md to describe the Secrets supported. I've hacked a wiki page https://wiki.jenkins.io/display/JENKINS/Kubernetes+Credentials+Provider+Plugin Add Comment This message
[JIRA] (JENKINS-50459) 401 when trying to update the build status in gitea
Title: Message Title
James Strachan created an issue
Jenkins / JENKINS-50459
401 when trying to update the build status in gitea
Issue Type:
Bug
Assignee:
Unassigned
Components:
gitea-plugin
Created:
2018-03-28 13:47
Environment:
Jenkins X with the gitea addon enabled on GKE
Priority:
Minor
Reporter:
James Strachan
I can use Jenkins X with gitea and the gitea-plugin to create repos & setup MultiBranchProjects for PRs/master and webhooks and all that are working great. However each pipeilne build fails to update the build status. Here's the exceptions that are generated at the beginning and end of a pipeline run. Its a little odd its a 401 as there's 1 credential used for querying the MBP branches, reading repos from gitea and doing commits/issues/PRs etc - so the credential is fine and the same credential is used in the Jenkins server config + the MBp Here's a sample stack trace at the start... [Gitea] Notifying branch build status: PENDING Build started... ERROR: Could not send notifications org.jenkinsci.plugin.gitea.client.api.GiteaHttpStatusException: HTTP 401/Unauthorized {"context":"test-user/environment-jstrachan-test8-staging/master","description":"Build started...","state":"pending","status":"pending","target_url":"http://jenkins.jx.35.197.207.229.nip.io/job/test-user/job/environment-jstrachan-test8-staging/job/master/2/display/redirect"} at org.jenkinsci.plugin.gitea.client.impl.DefaultGiteaConnection.post(DefaultGiteaConnection.java:911) at org.jenkinsci.plugin.gitea.client.impl.DefaultGiteaConnection.createCommitStatus(DefaultGiteaConnection.java:550) at org.jenkinsci.plugin.gitea.GiteaNotifier.sendNotifications(GiteaNotifier.java:144) at org.jenkinsci.plugin.gitea.GiteaNotifier.access$200(GiteaNotifier.java:66) at org.jenkinsci.plugin.gitea.GiteaNot
[JIRA] [core] (JENKINS-34170) support a watch REST API for jenkins resources?
Title: Message Title James Strachan created an issue Jenkins / JENKINS-34170 support a watch REST API for jenkins resources? Issue Type: Improvement Assignee: Unassigned Components: core Created: 2016/Apr/12 1:46 PM Priority: Minor Reporter: James Strachan One thing thats really nice about the kubernetes REST API is for any resource you can append "?watch=true" to the URL and you can upgrade from polling to watching resources over SPDY / websockets which can be a nice way to visualise things in a web page in real time without polling. I wonder has anyone ever tried adding a watch hook into the Jenkins REST API? Add Comment
[JIRA] [workflow-plugin] (JENKINS-33918) listener for pipeline build stage or step changes
Title: Message Title James Strachan created an issue Jenkins / JENKINS-33918 listener for pipeline build stage or step changes Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 2016/Mar/31 5:56 AM Labels: workflow pipeline Priority: Minor Reporter: James Strachan I tried using the BuildStepListener to be notified when a build step or stage was started/completed/failed but it doesn't seem to be invoked by the workflow/pipeline plugin. It'd be great to be able to listen to changes in pipeline's status (either at the stage or step level) for when steps start/complete/fail to aid visualisation and UX Add Comment
[JIRA] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan commented on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC Agreed 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan commented on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC We've just got Jenkernetes working; which uses a pod per slave with Swarm https://github.com/GoogleCloudPlatform/jenkernetes/ then using Docker in Docker (DIND) in each pod container so that each slave pod can create other docker containers (all inside the same single slave pod - these containers are invisible to kubernetes). So far its working quite well https://github.com/iocanel/jenkins-poc/tree/master/swarm After much head scratching trying to figure out how to get docker workflow, kubernetes, jenkins kubernetes plugin and/or jenkins docker plugin; we might have found a nice permutation! Many thanks! 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan closed an issue as Won't Fix doesn't seem possible Jenkins / JENKINS-29342 to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC Change By: James Strachan Status: Open Closed Resolution: Won't Fix 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan commented on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC OK - I guess DIND it is then! Thanks for listening 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan edited a comment on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC Yeah - to really use Pods properly on Kubernetes we'd need the master running the workflow to analyse the flow; figure out the pod/containers then create the 'slave' pod and wait for it to finish (and maybe restart it if it dies). If you kinda squint - this is almost like using "docker workflows pods" as a kinda slave in Jenkins (conceptually at least).It looks like Kubernetes isn't gonna support dynamic additions to a pod any time soon :(FWIW we've just had some success using Docker Workflow with DIND inside Swarm slaves using Jenkernetes on Kubernetes; which at least looks like it might work. https://github.com/iocanel/jenkins-poc/tree/master/swarmIts just a shame that all the docker containers inside the Swarm slave pod are kinda invisible from a Kubernetes tooling perspective (web UI / CLI) since they are all inside a docker-in-docker 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan commented on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC Yeah - to really use Pods properly on Kubernetes we'd need the master running the workflow to analyse the flow; figure out the pod/containers then create the pod and wait for it to finish (and maybe restart it if it dies). If you kinda squint - this is almost like using "docker workflows pods" as a kinda slave in Jenkins (conceptually at least). It looks like Kubernetes isn't gonna support dynamic additions to a pod any time soon FWIW we've just had some success using Docker Workflow with DIND inside Swarm slaves using Jenkernetes on Kubernetes; which at least looks like it might work. https://github.com/iocanel/jenkins-poc/tree/master/swarm Its just a shame that all the docker containers inside the Swarm slave pod are kinda invisible from a Kubernetes tooling perspective (web UI / CLI) since they are all inside a docker-in-docker 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan commented on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC A bit more background on this issue https://github.com/fabric8io/fabric8/issues/4340 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan commented on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC BTW here's our POC of trying to use Jenkins Docker Workflow on Kubernetes with slaves... https://github.com/iocanel/jenkins-poc so far the DIND was most promising but had issues https://github.com/iocanel/jenkins-poc/blob/master/slave-docker-in-docker/README.md 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] [workflow-plugin] (JENKINS-28718) withTool
Title: Message Title James Strachan commented on JENKINS-28718 Re: withTool Thanks and totally agreed - I'd prefer Docker Workflow! Its mostly the complexity of getting Docker Workflow working nicely in Kubernetes (see JENKINS-29342) that prompted me to go down the withTool hack 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] [kubernetes-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title James Strachan commented on JENKINS-29342 Re: to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC Jesse Glick so the general issue is the combination of 1 docker workflow script starting multiple docker containers; and those containers expecting to share a volume between them (so they can share the same workflow state). In kubernetes you can do that by using a persistent (distributed) shared disk and then running each docker container as a separate Pod and mounting this shared disk image; the only downside is thats kinda complex to do in Kubernetes and its highly cloud specific (whether using GKE's shared volumes or Gluster / Ceph et al) and I'm sure there could be all kinds of icky concurrency/distributed issues with disks not quite syncing correctly or out of order things happening etc. Since the workflow is parallel, any container could be reading/writing in any order etc. Another approach you can do is run 1 Pod which runs a separate local docker daemon and then run all the docker containers inside that single pod in a separate docker daemon. (So its Docker in Docker - or DIND); the main issue there is that it feels a bit like a hack and none of the kubernetes tooling can see these child docker images; so none of the tools for watching logs or doing 'docker exec' or even the docker CLI would work easily. So the other approach in kubernetes is if you put all the containers you're going to need together in a single pod; all those docker containers get put on the same host and can share local regular disk volumes with each other trivially. So turning a Jenkins Docker Workflow script into a Pod (so 1 container to run the workflow and another container for each docker.image() statement) would mean the entire workflow would run completely on a single host; could use shared disk easily (which also gets persisted if the pod dies and gets restarted elsewhere) and would mean all the kubernetes tooling would be able to look inside the workflow directly into any container; so you could watch/grep the logs of any of the containers; run bash inside the containers and see what they're up to etc. This last approach feels like the ideal way of combining Jenkins Docker Workflow with Kubernetes; it provides a simple way to do slaves (just run a k8s pod) and provides great tooling for developers to look inside builds that are not behaving as you expect etc - (just use kubernetes directly!). The only downside is we'd need a way for the master, when its about to start a Jenkins Workflow instance - to analyse the jenkins workflow DSL to figure out all the docker images that are going to be required; then a Pod can be built (which is basically a list of containers, their images, any CLI / env vars etc) - then the workflow could run as before. So a little bit of ninja Jenkins Workflow DSL stuff would be required to figure out the docker images that would be required before really running the workflow - but if we could do that then we'd have an amazing way to combine Jenkins Docker Workflows with Kubernetes Pods. One day - could be years off mind - there might be a way of dynamically adding Containers to a running Pod instance in kubernetes; which would make this really trivial to do in Jenkins Docker Workflow. We'd just start a Jenkins Workflow instance off in a Pod and add new containers as required to the Pod - but that doesn't look like happening any time soon; so we need to add all the containers into the pod up front right now. Until then, the "Docker in docker" hack
[JIRA] [workflow-plugin] (JENKINS-28718) withTool
Title: Message Title
James Strachan edited a comment on JENKINS-28718
Re: withTool
rather than globally configuring tools; it would be nice if a workflow could define the exact versions of tools it requires and cause them to be installed on the fly. So rather than using the globally installed tool IDs that must it might be installed globally nice to have something like:{code:java}withTool('maven', '3.2.2') { sh 'mvn package'}{code}then if version 3.2.2 is not installed yet, it would cause that version of maven to be installed. The DSL would then need to know how to install a specific version of common tools like maven / gradle etc. (e.g. using a template blob of XML which is parameterised by the version requested). This would allow the workflows workflow scripts to be in charge of what versions of tools they need; and not require global installations to be setup first . Kinda microservicey way of defining tools
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] [workflow-plugin] (JENKINS-28718) withTool
Title: Message Title
James Strachan commented on JENKINS-28718
Re: withTool
rather than globally configuring tools; it would be nice if a workflow could define the exact versions of tools it requires and cause them to be installed on the fly. So rather than using tool IDs that must be installed globally have something like:
withTool('maven', '3.2.2') {
sh 'mvn package'
}
then if version 3.2.2 is not installed yet, it would cause that version of maven to be installed. This would allow the workflows to be in charge of what versions of tools they need; and not require global installations to be setup first
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] [docker-workflow-plugin] (JENKINS-29342) to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Title: Message Title
James Strachan created an issue
Jenkins / JENKINS-29342
to use docker workflow nicely on kubernetes we should turn a docker workflow into a Pod/RC
Issue Type:
Improvement
Assignee:
Jesse Glick
Components:
docker-workflow-plugin
Created:
10/Jul/15 10:51 AM
Labels:
docker kubernetes
Priority:
Minor
Reporter:
James Strachan
when using kubernetes and jenkins docker workflow, its possible to use docker-in-docker (dind) in a slave or to try share the local docker daemon.
Though ideally it'd be great if using jenkins and kubernetes together (e.g. with Atomic / OpenShift / OpenStack / Google GKE / vanilla kubernetes) that we let kubernetes takes care of provisioning all the docker containers; pulling images and restarting any failed pods if the machine thats running a jenkins workflow has issues (or the pod dies).
To do that nicely on kubernetes we'd need to turn each Docker Workflow script into a Pod; with a docker container to run the main groovy workflow process; then for each container in the
docker.image("foo") {}
