-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Install a specific version #33
Comments
This is my question too |
https://help.ubuntu.com/community/PinningHowto might be the way to go, /etc/apt/preferences This is something we're only looking at experimenting with ourselves now for our Docker images, we'll let you know if we come up with an approach we can recommend, but for now, have a look at that wiki link. |
+1 It would be great to keep old versions available in Unfortunately pinning doesn't help when needing to provision new VM's to match machines in the cluster that are running an older version of the package. |
+1 for keeping old versions available in Need to be able to apt-get install a specific version (0.10.33 in this case) across multiple servers and then pin the nodejs package to maintain consistency and separately test new versions before rollout. Reference both https://help.ubuntu.com/community/PinningHowto and http://blog.andrewbeacock.com/2007/03/how-to-install-specific-version-of.html |
Okay, we certainly understand the need. Unfortunately, the |
What about at least providing one repo per major release series (e.g. 0.10.x, 0.12.x)? This is especially relevant now that Node 0.12 is out. I'd like to have control over when I make the switch from 0.10.x to 0.12.x. (But I am okay with receiving bugfix updates on the track that I'm on.) I feel like SaltStack PPAs do this well. (https://launchpad.net/~saltstack) In their case:
Going forward, I would love to see something similar for Node (e.g. repos |
This is an issue for us as well. I've switched to compiling from source for the moment as i'm not sure when the nodesouce repo will switch to a 0.12.x release. |
This really should be fixed, like many we test and lock to a specific release for production, we cannot have apt-get install nodejs=specific version fail because a new release was made nor can we accept every new release as if it were the one tested against. |
https://github.com/nodesource/docker-node has examples of installing specific versions of node/iojs on debian/ubuntu using dpkg and fedora/centos using rpm. You may want to do gpg verification as well, like https://github.com/iojs/docker-iojs/blob/master/1.6/Dockerfile#L11 |
Using Meteor and definitely need a way to pin the nodejs since there are version requirements. Thanks for all you you folks do on this distro! |
Friendly bump on this. I just got bit by a version update causing all of our builds to fail. Very unexpected that previous versions are wiped from the repo when a new one is released. |
@heston I believe they are only removed from the Personally I am pinning against specific versions using |
@wblankenship Thanks for the tip. Indeed, I see that the packages are still available, so that's an option. Without them being listed in the repo, it's not as easy to install with a package manager, though. We're using salt to manage our package installations. It has great support for |
@wblankenship Thanks for the tip too! Can someone from @nodesource please reply to this issue? We have occasional breaking builds as a result of this decision not to keep the packages around and we need to pin an exact version. At the risk of sounding off, an allegedly "enterprise" set of packages should really allow this simply. |
@conatus, thanks for your comment. We understand that this feature has been a pain point for some. I personally had to work with it when building the Docker images for NodeSource. @chrislea, @rvagg, and I are all on the @nodesource team. Our current build uses the We understand the need to pin to specific versions of Node in production. The rationale behind our Docker images is to support that specific use case. While we work towards a solution that allows We religiously keep all of the artifacts generated by our builds, incrementing the trailing digit of the
If you are using ansible, as @heston, the There is a similar story for our |
Thanks for your reply @wblankenship, very much appreciated. While this short term fix is certainly acceptable and the Dockerfiles are good examples, NodeSource isn't just any old set of builds. It is the set of builds recommended by the Node.js project itself as an install path. This repo is then a key bit of Node.js infrastructure for anyone running any kind of automation. You at @nodesource seem to intend it to be taken as such. So I hope you will consider working out how to pin versions easily as a matter of some priority in the near term. Thanks a lot. |
If it helps, Docker addressed a similar problem using |
Any word on this, aptly [1] works great for out internal repos, served from nginx. |
Yes, we will probably move to |
Any news on this? |
We switched from reprepro to Aptly for Yarn, and it works pretty well. I'd recommend it. |
…36837) Previously, in order to remain as deterministic as possible, the Dockerfile for the preview server Docker image had all dependencies pinned to specific versions. It turns out that some packages (such as `nginx`, `nodejs`, and `openssl` - potentially others too) make older versions unavailable on the repositories once a newer version is available. See for example: - nodesource/distributions#33 - https://askubuntu.com/questions/715104/how-can-i-downgrade-openssl-via-apt-get This commit, therefore, removes the exact versions for these packages. The latest versions will be installed everytime the Docker image is built (subject to Docker caching). PR Close #36837
…36837) Previously, in order to remain as deterministic as possible, the Dockerfile for the preview server Docker image had all dependencies pinned to specific versions. It turns out that some packages (such as `nginx`, `nodejs`, and `openssl` - potentially others too) make older versions unavailable on the repositories once a newer version is available. See for example: - nodesource/distributions#33 - https://askubuntu.com/questions/715104/how-can-i-downgrade-openssl-via-apt-get This commit, therefore, removes the exact versions for these packages. The latest versions will be installed everytime the Docker image is built (subject to Docker caching). PR Close #36837
…ngular#36837) Previously, in order to remain as deterministic as possible, the Dockerfile for the preview server Docker image had all dependencies pinned to specific versions. It turns out that some packages (such as `nginx`, `nodejs`, and `openssl` - potentially others too) make older versions unavailable on the repositories once a newer version is available. See for example: - nodesource/distributions#33 - https://askubuntu.com/questions/715104/how-can-i-downgrade-openssl-via-apt-get This commit, therefore, removes the exact versions for these packages. The latest versions will be installed everytime the Docker image is built (subject to Docker caching). PR Close angular#36837
NodeSource, while handy, does not support version pinning. As such it would be impossible for us to ensure that the image can be reproduced. See nodesource/distributions#33. Included is also a script to update the containers version of NodeJS automatically, pending integration with CI.
NodeSource, while handy, does not support version pinning. As such it would be impossible for us to ensure that the image can be reproduced. See nodesource/distributions#33. Included is also a script to update the containers version of NodeJS automatically, pending integration with CI.
NodeSource, while handy, does not support version pinning. As such it would be impossible for us to ensure that the image can be reproduced. See nodesource/distributions#33. Included is also a script to update the containers version of NodeJS automatically, pending integration with CI.
Just to add to #33 (comment) I use the Dockerfile approach for building Expo tooling with Gradle on JDK8.
|
@retrohacker
But i ran into this error:
I tried adding |
I took the instructions from the GitHub issue which I updated to point to the exact comment which shows how to pin the Node version to a specific number. But since this issue is still being updated, as 27 days ago at the time this was written, I figured I'd leave a link to the comment which could give us issues updated to this version of Node LTS. Comment talking about a dependency on python2: nodesource/distributions#33 (comment)
@e-dong I faced the Running this on a totally fresh machine caused no issues, for instance.
(Sorry this comment isn't fully baked; I wanted to mention the clue for future folks facing the problem) |
FYI: I was able to resolve the It seems the file with |
When I switched to using the
|
Good example why pinning is extremely important: We are not sure what to do now with all builds failing |
you are a legend, thanks |
A new proper way to do this, per official documentation, is here:
|
How would you recommend that someone use this repository to install a specific version of Node.js? Previously, I was attempting to pin the version number, but it looks like older versions of Node.js are being replaced with newer ones.
My goal is to use a specific version of Node.js, but then not update to the newest version until after some testing occurs.
The text was updated successfully, but these errors were encountered: