[JIRA] (JENKINS-37419) Git plugin checking out non-existent submodule from different branch
Title: Message Title Ethan Trewhitt commented on JENKINS-37419 Re: Git plugin checking out non-existent submodule from different branch Submitted PR 230, which aims to fix this one. 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-40171) The "Apply" button's "Saved" message obstructs the top menu
Title: Message Title Ethan Trewhitt created an issue Jenkins / JENKINS-40171 The "Apply" button's "Saved" message obstructs the top menu Issue Type: Improvement Assignee: Unassigned Components: core Created: 2016/Dec/01 9:59 PM Priority: Trivial Reporter: Ethan Trewhitt Clicking "Apply" on a project configuration screen creates a message popup at the top of the current viewport in the web UI. It fades in and obstructs the top menu. Since a common operation during project design is to click "Build Now" for the project, that's a very minor annoyance. It's so trivial that I hesitated to submit this ticket, but it's just one of those niceties that would be better if it were different. Add Comment
[JIRA] (JENKINS-40170) Separate execution functionality of image.inside() into distinct steps
Title: Message Title
Ethan Trewhitt updated an issue
Jenkins / JENKINS-40170
Separate execution functionality of image.inside() into distinct steps
Change By:
Ethan Trewhitt
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 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?
Add Comment
This message was sent by Atlassian JIRA
[JIRA] (JENKINS-40170) Separate execution functionality of image.inside() into distinct steps
Title: Message Title
Ethan Trewhitt updated an issue
Jenkins / JENKINS-40170
Separate execution functionality of image.inside() into distinct steps
Change By:
Ethan Trewhitt
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?
Add Comment
This message was sent by Atlassian JIRA
[JIRA] (JENKINS-40170) Separate execution functionality of image.inside() into distinct steps
Title: Message Title
Ethan Trewhitt updated an issue
Jenkins / JENKINS-40170
Separate execution functionality of image.inside() into distinct steps
Change By:
Ethan Trewhitt
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?
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40170) Separate execution functionality of image.inside() into distinct steps
Title: Message Title
Ethan Trewhitt created an issue
Jenkins / JENKINS-40170
Separate execution functionality of image.inside() into distinct steps
Issue Type:
New Feature
Assignee:
Unassigned
Components:
docker-workflow-plugin
Created:
2016/Dec/01 9:37 PM
Priority:
Minor
Reporter:
Ethan Trewhitt
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?
[JIRA] (JENKINS-40168) Make the override of ENTRYPOINT by image.inside optional
Title: Message Title Ethan Trewhitt created an issue Jenkins / JENKINS-40168 Make the override of ENTRYPOINT by image.inside optional Issue Type: Improvement Assignee: Unassigned Components: docker-workflow-plugin Created: 2016/Dec/01 9:22 PM Priority: Major Reporter: Ethan Trewhitt The change made to address JENKINS-37987 breaks Docker images that use a specific ENTRYPOINT to start services. Any Docker image based on the common scenario of using supervisord to run a set of daemons will break with the override of ENTRYPOINT and CMD by image.inside, which overrides the command to "cat" to keep the image alive. While some users may need that behavior, many of us would prefer to control that directly. Add Comment
[JIRA] (JENKINS-37495) [REGRESSION] Git Submodules having a name different to their path in working tree, failing to checkout
Title: Message Title Ethan Trewhitt edited a comment on JENKINS-37495 Re: [REGRESSION] Git Submodules having a name different to their path in working tree, failing to checkout I've created a pull request that should address this issue:https://github.com/jenkinsci/git-client-plugin/pull/ 224 225 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-37419) Git plugin checking out non-existent submodule from different branch
Title: Message Title Ethan Trewhitt updated an issue Jenkins / JENKINS-37419 Git plugin checking out non-existent submodule from different branch Change By: Ethan Trewhitt Comment: I've committed a pull request that attempts to fix this bug. It pulls from .gitmodules rather than the repo-level git config. That file should be up-to-date with only the list of modules active in the current branch/commit/HEAD.https://github.com/jenkinsci/git-client-plugin/pull/224 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-37419) Git plugin checking out non-existent submodule from different branch
Title: Message Title Ethan Trewhitt commented on JENKINS-37419 Re: Git plugin checking out non-existent submodule from different branch I've committed a pull request that attempts to fix this bug. It pulls from .gitmodules rather than the repo-level git config. That file should be up-to-date with only the list of modules active in the current branch/commit/HEAD. https://github.com/jenkinsci/git-client-plugin/pull/224 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-37495) [REGRESSION] Git Submodules having a name different to their path in working tree, failing to checkout
Title: Message Title Ethan Trewhitt commented on JENKINS-37495 Re: [REGRESSION] Git Submodules having a name different to their path in working tree, failing to checkout I've created a pull request that should address this issue: https://github.com/jenkinsci/git-client-plugin/pull/224 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.
