Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FIXED JENKINS-46277] Do a pull for stage-level docker agent too #182

Merged
merged 1 commit into from Aug 21, 2017

Conversation

abayer
Copy link
Member

@abayer abayer commented Aug 17, 2017

  • JENKINS issue(s):
  • Description:
    • When we're at the top level, we want do do a pull of the docker image, but we want to do it within a synthetic stage. That's all well and good, but until now, the way this was done meant we weren't doing an image pull if we were at the stage level. That was dumb. Fixed!
  • Documentation changes:
    • n/a
  • Users/aliases to notify:
    • @reviewbybees

@abayer abayer added this to the 1.2 milestone Aug 17, 2017
@abayer abayer requested a review from rsandell August 17, 2017 16:39
@ghost
Copy link

ghost commented Aug 17, 2017

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

Copy link
Member

@rsandell rsandell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐝

@@ -50,6 +50,9 @@ public class DockerPipelineScript extends AbstractDockerPipelineScript<DockerPip
}
}
try {
if (Utils.withinAStage()) {
script.getProperty("docker").image(describable.image).pull()
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But doesn't the line below pull the image if it doesn't exist already?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it doesn't exist, yes, but it doesn't update if there's a newer version.

@abayer abayer merged commit 8aa1650 into jenkinsci:master Aug 21, 2017
@oysols
Copy link

oysols commented Sep 25, 2017

If you do not use a docker registry this change breaks the pipeline. Previously it was enough to keep the images locally, but this pull obviously fails if the images only exist locally.

The simple workaround is to patch the plugin to revert this change, but it would be nice to avoid that. If you think pull by default is the right thing, fine, but I think it makes sense to make it configurable.

Am I missing something? Is there some way to make it work with local images?

@abayer
Copy link
Member Author

abayer commented Sep 25, 2017

@oysols Argh! Very sorry to hear that - could you open an issue at issues.jenkins-ci.org? I'm planning a 1.2.1 release for probably end of this week and will try to find a good option here.

@oysols
Copy link

oysols commented Sep 25, 2017

Opened an issue: https://issues.jenkins-ci.org/browse/JENKINS-47106
Let me know if it needs more specifics.

@Danack
Copy link

Danack commented Sep 27, 2017

Thank-you @oysols for opening the issue.

I think it would be appropriate for the priority to be updated to be 'major' or 'critical', and for there to be some announcement about this being a breaking bug.

Upgrading to this version of the plugin, when you have images that are stored locally, apparently breaks the build pipeline.

So anyone using the previous version and having local images in their pipeline need to be aware this bug will break their build.

(apologies in advance for cross-posting, but this caused quite a bit of headaches for us, which other people shouldn't have to suffer.)

@abayer
Copy link
Member Author

abayer commented Sep 27, 2017

I'll be fixing the issue today or tomorrow, with a release planned for Friday, FYI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants