-
New Feature
-
Resolution: Unresolved
-
Minor
-
None
Image.inside() performs a number of tasks that are useful in many cases. Unfortunately it also performs one task that cannot directly be performed with any other Groovy step: actually running code in the image. The execution step should be separated from the other steps performed by inside() so that users can control what happens. If this means that inside() remains the same, while a new method is created that only executes code within the running container, that's fine. It's already a bit strange that "inside" is attached to the "Image" object, since the code is actually being executed inside a container instantiated from that image.
May I suggest adding a some functions to the "container" object so that we can do this? I would envision this process to look something like this:
node {
def image = docker.image('metatest')
def container = image.run()
container.execInside() {
step("Get Username") {
sh "whoami"
}
step("Report Success") {
sh "echo Success!"
}
}
container.stop()
container.remove()
}
Note that I have also separated the stop and rm steps for the container. I see no reason why they should be combined in the stop() method. Why not mirror the Docker commands with the same name?
- relates to
-
-
- In Review
-
[JENKINS-40170] Separate execution functionality of image.inside() into distinct steps
| Description |
Original:
Image.inside() performs a number of tasks that are useful in many cases. Unfortunately it also performs one task that cannot directly be performed with any other Groovy step: actually running code in the image. The execution step should be separated from the other steps performed by inside() so that users can control what happens. If this means that inside() remains the same, while a new method is created that _only_ executes code within the running container, that's fine. It's already a bit strange that "inside" is attached to the "Image" object, since the code is actually being executed inside a container instantiated from that image. May I suggest adding a some functiosn to the "container" object so that we can do this? I would envision this process to look something like this: {{ node { def image = docker.image('metatest') def container = image.run() container.execInside() { sh "whoami" sh "echo Success!" } container.stop() container.remove() } }} Note that I have also separated the _stop_ and _rm_ steps for the container. I see no reason why they should be combined in the stop() method. Why not mirror the Docker commands with the same name? |
New:
Image.inside() performs a number of tasks that are useful in many cases. Unfortunately it also performs one task that cannot directly be performed with any other Groovy step: actually running code in the image. The execution step should be separated from the other steps performed by inside() so that users can control what happens. If this means that inside() remains the same, while a new method is created that _only_ executes code within the running container, that's fine. It's already a bit strange that "inside" is attached to the "Image" object, since the code is actually being executed inside a container instantiated from that image. May I suggest adding a some functiosn to the "container" object so that we can do this? I would envision this process to look something like this: node { def image = docker.image('metatest') def container = image.run() container.execInside() { step("Get Username") { sh "whoami" } step("Report Success") { sh "echo Success!" } } container.stop() container.remove() } Note that I have also separated the _stop_ and _rm_ steps for the container. I see no reason why they should be combined in the stop() method. Why not mirror the Docker commands with the same name? |
| Description |
Original:
Image.inside() performs a number of tasks that are useful in many cases. Unfortunately it also performs one task that cannot directly be performed with any other Groovy step: actually running code in the image. The execution step should be separated from the other steps performed by inside() so that users can control what happens. If this means that inside() remains the same, while a new method is created that _only_ executes code within the running container, that's fine. It's already a bit strange that "inside" is attached to the "Image" object, since the code is actually being executed inside a container instantiated from that image. May I suggest adding a some functiosn to the "container" object so that we can do this? I would envision this process to look something like this: node { def image = docker.image('metatest') def container = image.run() container.execInside() { step("Get Username") { sh "whoami" } step("Report Success") { sh "echo Success!" } } container.stop() container.remove() } Note that I have also separated the _stop_ and _rm_ steps for the container. I see no reason why they should be combined in the stop() method. Why not mirror the Docker commands with the same name? |
New:
Image.inside() performs a number of tasks that are useful in many cases. Unfortunately it also performs one task that cannot directly be performed with any other Groovy step: actually running code in the image. The execution step should be separated from the other steps performed by inside() so that users can control what happens. If this means that inside() remains the same, while a new method is created that _only_ executes code within the running container, that's fine. It's already a bit strange that "inside" is attached to the "Image" object, since the code is actually being executed inside a container instantiated from that image. May I suggest adding a some functiosn to the "container" object so that we can do this? I would envision this process to look something like this: {code} node { def image = docker.image('metatest') def container = image.run() container.execInside() { step("Get Username") { sh "whoami" } step("Report Success") { sh "echo Success!" } } container.stop() container.remove() } {code} Note that I have also separated the _stop_ and _rm_ steps for the container. I see no reason why they should be combined in the stop() method. Why not mirror the Docker commands with the same name? |
| Description |
Original:
Image.inside() performs a number of tasks that are useful in many cases. Unfortunately it also performs one task that cannot directly be performed with any other Groovy step: actually running code in the image. The execution step should be separated from the other steps performed by inside() so that users can control what happens. If this means that inside() remains the same, while a new method is created that _only_ executes code within the running container, that's fine. It's already a bit strange that "inside" is attached to the "Image" object, since the code is actually being executed inside a container instantiated from that image. May I suggest adding a some functiosn to the "container" object so that we can do this? I would envision this process to look something like this: {code} node { def image = docker.image('metatest') def container = image.run() container.execInside() { step("Get Username") { sh "whoami" } step("Report Success") { sh "echo Success!" } } container.stop() container.remove() } {code} Note that I have also separated the _stop_ and _rm_ steps for the container. I see no reason why they should be combined in the stop() method. Why not mirror the Docker commands with the same name? |
New:
Image.inside() performs a number of tasks that are useful in many cases. Unfortunately it also performs one task that cannot directly be performed with any other Groovy step: actually running code in the image. The execution step should be separated from the other steps performed by inside() so that users can control what happens. If this means that inside() remains the same, while a new method is created that _only_ executes code within the running container, that's fine. It's already a bit strange that "inside" is attached to the "Image" object, since the code is actually being executed inside a container instantiated from that image. May I suggest adding a some functions to the "container" object so that we can do this? I would envision this process to look something like this: {code} node { def image = docker.image('metatest') def container = image.run() container.execInside() { step("Get Username") { sh "whoami" } step("Report Success") { sh "echo Success!" } } container.stop() container.remove() } {code} Note that I have also separated the _stop_ and _rm_ steps for the container. I see no reason why they should be combined in the stop() method. Why not mirror the Docker commands with the same name? |
courtarro yes this would probably be a useful refactoring. Related to PR 78. Your example would better use withRun however.
nickolasfox your comment makes no sense that I can see. Your script is already valid.
| Link | New: This issue relates to JENKINS-39748 [ JENKINS-39748 ] |
This snippet works fine to me, so there's one step outside docker environment just to checkout scm changes and the following ones are running inside docker container.
node (dockerNode) { def dockerEnv = docker.image("some-our-internal-image") stage("Prepare environment"){ setupEnvironment() checkout scm } dockerEnv.inside{ stage('Run API Tests') setupDependencies() startServices() runAPITests() } stage('Run UI Tests'){ setupUIDependencies() runUITests() } stage("Run E2E Tests"){ setupE2EEnvironment() setupXServerDependencies() setupUIDependencies() setupProductionLikeEnvironmentDependencies() runE2ETests() } } }