Feature request: A check box for specifying whether to pull the corresponding repository before launching the container #79
Comments
|
+1 |
|
+1, so far it is just pulled if it doesn't exist, pulling every time is good feature to have |
|
Yes, definitely want this. |
|
Great idea. |
|
Does the java docker client lib already offer the ability to just pull a repo and do nothing else? So it would only be a checkbox within docker-plugin, that triggers the pull? |
|
I began to create a pull request branching from master, but I encountered problems building the project. (Some docker-java dependency problems.) I tried to bump the docker-java version from 0.10.5-SNAPSHOT to 0.10.5, but that didn't work either (some packages referenced no longer exist in that version it seems.) My (untested) fix for this issue is here in a .diff format. https://gist.github.com/halvorgb/c19c5076ffe6c23f65c0 Is there some known commit i could check out that builds? If my understanding is correct, this fix would be a simple one and I've already done most of it. |
|
You can use the @magnayn docker-java if you add a snapshot repo #143 (comment) |
|
+1 FYI, when I did some work on a Jenkins enhancement, I found that there was a cloudbees server looking for pull requests on the source such that all one needed to do was to issue a pull request (via GitHub) and it'd automatically build and test your source for you, and let you know if it thought the pull request looked good or not. As for the code itself, it seemed to me like the proposed code changes would result in it fetching the image whether or not it needed to. Personally, I'd prefer to see it doing some form of up-to-date check rather than a brute-force "just re-fetch it all anyway" approach. Not sure how easy that would be to achieve though... |
|
@pjdarton sorry i don't understand what do you mean and what are you talking about. If there is different use cases, then feature should have different modes/strategies. |
|
At present, the official plugin only fetches the image if it doesn't have a copy of that image. It does not check that copy it has matches the one in the repository, so if it has previously fetched "foo:latest" then even if there's a new "foo:latest" it will continue using the old version of foo. With the proposed changes, I think that the code will re-fetch "foo:latest" whether or not the repository has a new version of foo. This means that, in the (common) situation where foo has not changed and the cached copy of foo:latest is the same as the one in the repository, the code would still re-fetch foo:latest and overwrite what it has with an identical copy. i.e. at present, the code does "download only if we don't have any copy", the proposed change is to "download a new copy every time", and my suggestion is to "check for an update every time and only download if a new copy is available or if we don't have a copy at all". The point is that, if your specification is that a slave should use "foo:latest" then it should run on the latest version of foo (I think we're in agreement on this point), and so each time a new version of foo is created and the "latest" tag is updated to point at that new version then the new version should be downloaded (and I think we agree on this too), but (and this is where we differ) if foo doesn't change then there shouldn't be any unnecessary downloading. |
|
@pjdarton i know what is this issue/request about and how this can be implemented. I don't understand this comments:
|
|
One creates a fork of the code on GitHub, do work, putting your changes into that fork, and then one issues a "pull request" (using the GitHub web interface). I don't know if such a facility is set up for this plugin's code, but there was (and probably still is) one for the core Jenkins code, and as the proposed fix mentioned "problems building the project" that were preventing the contributor from testing their fix, I thought this could be relevant. Regarding the -SNAPSHOT comment - responsibility for doing that typically lies with the person/people who have the authority/access to action a "pull request". You appear to have "commit" rights to this repository, so I assume that includes you. |
|
Your are commenting "feb 13" repository state and now 23 apr. Library issues were resolved, master is buildable, pr builds works for all plugins hosted under @jenkinsci. |
|
The latest version of the plugin (according to the Jenkins update site, http://updates.jenkins-ci.org/download/plugins/docker-plugin/) is 0.8, and that was released on Oct 2014, which implies that nothing has been released since then. That's why I assumed that the "feb 13" comments are still relevant. If there is an updated version of the plugin, please publish it. |
|
It available in experimental plugin update center, there is also #177 new beta will be published soon. Release will be done when build will be stable. |
|
What is the URL for the "experimental plugin update center" that you refer to? Also, can you give me an estimate when the next official release will be? |
|
http://jenkins-ci.org/content/experimental-plugins-update-center |
|
Thanks for the info. I'll take a look and see if that solves the problem (that this thread was about) for us. Re: estimates - no problem - I understand. |
|
@magnayn As temp solution i think it makes sense to change default behaviour to pull ":latest" every time and other only when doesn't exist. Later this can be moved to default pulling strategy with some other variants like "never pull strategy" and etc. |
|
Hi all, does anyone wants test #289 ? |
|
Hi @KostyaSha. I get the following error on Jenkins start up: Am I missing something in addition to the .hpi? |
|
Yes, you need token-macro plugin. Better install docker-plugin from update center and then update docker-plugin hpi. Either you need install all dependencies manually. |
|
Thanks for the quick reply. Manually installing the token-macro plugin fixed the initial issue. I appear to have further dependency issues This is after a fresh install of Jenkins and docker-plugin 0.10.2. I have tried updating the plugin to 0.10.3 through the advanced tab under Manage Plugins settings. I've also tried simply replacing the .jpi in my JENKINS_HOME/plugins/ folder. If I am missing further dependencies, I don't see why they were not installed when I installed version 0.10.2? |
|
Remove jpi and hpi for docker-plugin and put new hpi |
|
I have done this and have the same |
|
Strange, because docker-plugin is not using this classes. |
|
Could you provide list of installed plugins? |
|
If it is still useful, these are the installed plugins If there is a new plugin built after the shaded library has been fixed, I will be happy to test it asap |
|
Please try https://jenkins.ci.cloudbees.com/job/plugins/job/docker-plugin/443/com.nirima$docker-plugin/ but firstly remove old jpl/jpi/hpi files |
|
I removed the old hpi and the docker-plugin folder in JENKINS_HOME/plugins and replaced it with the hpi from the build. But I still have the same NoClassDefFound error |
|
It would be good to see if this problem can be recreated by someone else to ensure it's not only my environment. Is anyone else able to test the plugin? |
|
I have had a colleague test build 443 on a different machine, by installing 0.10.2 and replacing the hpi with the 0.10.3 snapshot. He also gets the same |
|
It was a regression in PR builder https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-dev/8x2nrUwHg60/dVj7r5XzAwAJ |
|
What I assume was your local build (from dropbox) gave Config.xml for reference I will try build 445 |
|
Same Bad Template error on pr build 445 |
|
I removed the cloud configuration and re-added it after installing build 445 to see if it was old 0.10.2 configurations not working with the new plugin. Same error |
|
Thanks, @DanielHouston could your provide log from system jenkins log? |
|
You're welcome. Logs since latest reboot: Unfortunately not a lot of information here! |
|
And system logger for |
|
I don't seem to get any more output with level ALL |
|
Ok, i will verify myself later |
|
@KostyaSha More good news, the pull strategy changes also appear to be working :) 👍 |
|
Maybe dirty hack that i removed was related to this NPE, i will check on weekend. |
|
@DanielHouston thanks, fixed. |
|
Merged, will be released after @DanielHouston master testing |
|
Everything is looking like it is working :) |
|
Good catch, i forgot about nice logging |
|
If you are in there changing the log message, if at all possible, please could you add in a note to say how long the pull took? The total number of seconds (s) or in milliseconds (ms) would be ideal |
|
ok |
pjdarton
added
RFE
Hi, i want my docker cloud instances to always use the latest image for a resulting container. Therefore it would be nice, to first pull the repository on the docker host.
So every time i build a new image and push it to the registry it will soon be used by all the cloud instances.
The text was updated successfully, but these errors were encountered: