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

Set docker-compose version to latest #30

Open
nickelozz opened this issue Jun 15, 2016 · 8 comments
Open

Set docker-compose version to latest #30

nickelozz opened this issue Jun 15, 2016 · 8 comments

Comments

@nickelozz
Copy link

Is there any way to achieve setting docker-compose version to latest stable? Just like the docker installation defaults to latest stable version.

@leighmcculloch
Copy link
Owner

Unfortunately the download URLs for docker-compose don't have a latest URL that will always get the latest. But you can configure the version being downloaded by setting compose_version and I also try and keep this project up to date with the latest version. If you're using the latest version of this plugin, whenever you update the plugin it will auto-update docker-compose inside your vagrant instance (unless you override and lock the compose_version to something specific).

@prilka
Copy link

prilka commented Sep 19, 2019

@leighmcculloch It's possible to determine the latest docker-compose version. The URL https://github.com/docker/compose/releases/latest will always redirect to the latest version, so the Location-Header contains the needed informationen.

I'm not an ruby developer, but i think it's possible to replace this line

comm.sudo("curl -L https://github.com/docker/compose/releases/download/#{config.compose_version}/docker-compose-`uname -s`-`uname -m` > #{config.executable_install_path}")

with something like this

version = config.compose_version
if version == 'latest'
    version = Net::HTTP.get_response(URI('https://github.com/docker/compose/releases/latest'))['Location'].split('/').last
end
comm.sudo("curl -L https://github.com/docker/compose/releases/download/#{version}/docker-compose-`uname -s`-`uname -m` > #{config.executable_install_path}")

The default value for the compose_version config should then be changed to latest.

I would create a pull-request, but i have no idea how to test/debug a vagrant plugin.

@leighmcculloch
Copy link
Owner

@prilka Thanks for the suggestion! That's a great idea.

@leighmcculloch
Copy link
Owner

One downside to doing this is it will make using the package unpredictable. If you have a specific version of the plugin installed, over time the version of docker-compose changes, which makes a development environment unpredictable.

I'm guessing not a lot of people are pinning vagrant plugin versions though, so this is probably mute, and latest is more likely to help than hinder folks.

I'm working on adding latest using the above idea.

@leighmcculloch leighmcculloch self-assigned this Sep 23, 2019
@prilka
Copy link

prilka commented Sep 23, 2019

One downside to doing this is it will make using the package unpredictable. If you have a specific version of the plugin installed, over time the version of docker-compose changes, which makes a development environment unpredictable.

That's true, but it's the same behavior as with most package-managers (e.g. pip install docker-compose). Developers who prefer a predictable version can set the desired version in their config via compose_version.

I'm working on adding latest using the above idea.

nice, thank you 👍

@leighmcculloch leighmcculloch added this to the v1.6.0 milestone Sep 28, 2019
@leighmcculloch
Copy link
Owner

I think the approach I'll take is to use the GitHub API, with something akin to the following:

curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r '.name'

Right now this returns 1.24.1.

The downside to using the GitHub API is that rate limiting will set in if someone, or the NAT they are behind, is hitting the API a lot.

Using the 301/302 redirect on the URL won't have the rate limit.

@prilka
Copy link

prilka commented Oct 8, 2019

The rate limit is really annoying for agencies with a shared ip. The solution with the redirect parsing works well and stable. I use it in some provisioning-scripts for quite a while.

@leighmcculloch
Copy link
Owner

That's a good point. 👍

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

No branches or pull requests

3 participants