Install a specific version #33

Open
hectcastro opened this Issue Oct 27, 2014 · 36 comments

Comments

Projects
None yet
@hectcastro

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.

@Jellyrick

This comment has been minimized.

Show comment
Hide comment
@Jellyrick

Jellyrick Oct 29, 2014

This is my question too

This is my question too

@rvagg

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Oct 29, 2014

Member

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.

Member

rvagg commented Oct 29, 2014

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.

@zol

This comment has been minimized.

Show comment
Hide comment
@zol

zol Dec 15, 2014

+1 It would be great to keep old versions available in Packages rather than just the latest.

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.

zol commented Dec 15, 2014

+1 It would be great to keep old versions available in Packages rather than just the latest.

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.

@tecto

This comment has been minimized.

Show comment
Hide comment
@tecto

tecto Jan 3, 2015

+1 for keeping old versions available in Packages.

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

tecto commented Jan 3, 2015

+1 for keeping old versions available in Packages.

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

@chrislea

This comment has been minimized.

Show comment
Hide comment
@chrislea

chrislea Jan 3, 2015

Contributor

Okay, we certainly understand the need. Unfortunately, the reprepro utility which is part of our tooling for publishing the repositories can't do this, so we'll need to look into using something like aptly instead. I'll update here once we have something ready.

Contributor

chrislea commented Jan 3, 2015

Okay, we certainly understand the need. Unfortunately, the reprepro utility which is part of our tooling for publishing the repositories can't do this, so we'll need to look into using something like aptly instead. I'll update here once we have something ready.

@chris-prince

This comment has been minimized.

Show comment
Hide comment
@chris-prince

chris-prince Feb 7, 2015

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:

  • ppa:saltstack/salt gives the latest stable release
  • ppa:saltstack/salt2014-7 gives the latest stable v2014.7.x release
  • ppa:saltstack/salt2014-1 gives the latest stable v2014.1.x release
  • etc.

Going forward, I would love to see something similar for Node (e.g. repos node, node-0.10, node-0.12).

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:

  • ppa:saltstack/salt gives the latest stable release
  • ppa:saltstack/salt2014-7 gives the latest stable v2014.7.x release
  • ppa:saltstack/salt2014-1 gives the latest stable v2014.1.x release
  • etc.

Going forward, I would love to see something similar for Node (e.g. repos node, node-0.10, node-0.12).

@coen-hyde

This comment has been minimized.

Show comment
Hide comment
@coen-hyde

coen-hyde Feb 11, 2015

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 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.

@awithersdd

This comment has been minimized.

Show comment
Hide comment
@awithersdd

awithersdd Apr 3, 2015

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.

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.

@retrohacker

This comment has been minimized.

Show comment
Hide comment
@retrohacker

retrohacker Apr 4, 2015

Contributor

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

Contributor

retrohacker commented Apr 4, 2015

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

@shrop

This comment has been minimized.

Show comment
Hide comment
@shrop

shrop Jul 25, 2015

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!

shrop commented Jul 25, 2015

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!

@heston

This comment has been minimized.

Show comment
Hide comment
@heston

heston Dec 10, 2015

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 commented Dec 10, 2015

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.

@retrohacker

This comment has been minimized.

Show comment
Hide comment
@retrohacker

retrohacker Dec 10, 2015

Contributor

@heston I believe they are only removed from the Release file. They are still in the repo: https://deb.nodesource.com/node_5.x/pool/main/n/nodejs/

Personally I am pinning against specific versions using wget [deb] && dpkg -i [deb].

Contributor

retrohacker commented Dec 10, 2015

@heston I believe they are only removed from the Release file. They are still in the repo: https://deb.nodesource.com/node_5.x/pool/main/n/nodejs/

Personally I am pinning against specific versions using wget [deb] && dpkg -i [deb].

@heston

This comment has been minimized.

Show comment
Hide comment
@heston

heston Dec 10, 2015

@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 apt-get, but doesn't work as well with custom installation procedures.

heston commented Dec 10, 2015

@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 apt-get, but doesn't work as well with custom installation procedures.

@conatus

This comment has been minimized.

Show comment
Hide comment
@conatus

conatus Jan 6, 2016

@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 commented Jan 6, 2016

@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.

@retrohacker

This comment has been minimized.

Show comment
Hide comment
@retrohacker

retrohacker Jan 6, 2016

Contributor

@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 reprepro tool from the Debian project to host these repositories. As chrislea commented above, the tool is preventing us from doing this. We are looking into alternatives that will offer this feature.

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 apt to directly pin a version, we have a short term solution that I proposed above.

We religiously keep all of the artifacts generated by our builds, incrementing the trailing digit of the .deb in the event we need to do a rebuild. They all exist on deb.nodesource.com. This allows consumers to pin directly to a version of Node. The pools these artifacts are served from can be found at:

If you are using ansible, as @heston, the apt package supports the deb flag which takes a path to a .deb file on the remote box. Pairing this with get_url will offer a short term solution to version pinning.

There is a similar story for our rpm packages as well.

Contributor

retrohacker commented Jan 6, 2016

@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 reprepro tool from the Debian project to host these repositories. As chrislea commented above, the tool is preventing us from doing this. We are looking into alternatives that will offer this feature.

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 apt to directly pin a version, we have a short term solution that I proposed above.

We religiously keep all of the artifacts generated by our builds, incrementing the trailing digit of the .deb in the event we need to do a rebuild. They all exist on deb.nodesource.com. This allows consumers to pin directly to a version of Node. The pools these artifacts are served from can be found at:

If you are using ansible, as @heston, the apt package supports the deb flag which takes a path to a .deb file on the remote box. Pairing this with get_url will offer a short term solution to version pinning.

There is a similar story for our rpm packages as well.

@conatus

This comment has been minimized.

Show comment
Hide comment
@conatus

conatus Jan 6, 2016

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.

conatus commented Jan 6, 2016

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.

@leedm777

This comment has been minimized.

Show comment
Hide comment
@leedm777

leedm777 Jan 25, 2016

If it helps, Docker addressed a similar problem using reprepro with their patch at moby/moby#16001. Maybe NodeSource can do something similar.

If it helps, Docker addressed a similar problem using reprepro with their patch at moby/moby#16001. Maybe NodeSource can do something similar.

@klardotsh klardotsh referenced this issue in geerlingguy/ansible-role-nodejs Feb 11, 2016

Merged

Add nodejs 5.x support for Debian systems #16

@nicholascapo

This comment has been minimized.

Show comment
Hide comment
@nicholascapo

nicholascapo Mar 31, 2016

Any word on this, aptly [1] works great for out internal repos, served from nginx.

[1] https://www.aptly.info/

Any word on this, aptly [1] works great for out internal repos, served from nginx.

[1] https://www.aptly.info/

@chrislea

This comment has been minimized.

Show comment
Hide comment
@chrislea

chrislea Mar 31, 2016

Contributor

Yes, we will probably move to aptly since it seems like the best tool that will let us do this. Unfortunately the way the builds are currently automated is fairly tied to reprepro so this isn't a trivial change to make. It will almost certainly happen when we move the repos to be served off of S3 / CloudFront. So both of those are things on the TODO list, but right now there are a couple of other infrastructure updates that we have to make first internally, so these aren't at the top of the list right now.

Contributor

chrislea commented Mar 31, 2016

Yes, we will probably move to aptly since it seems like the best tool that will let us do this. Unfortunately the way the builds are currently automated is fairly tied to reprepro so this isn't a trivial change to make. It will almost certainly happen when we move the repos to be served off of S3 / CloudFront. So both of those are things on the TODO list, but right now there are a couple of other infrastructure updates that we have to make first internally, so these aren't at the top of the list right now.

@danielkza

This comment has been minimized.

Show comment
Hide comment
@danielkza

danielkza Feb 3, 2017

Any news on this?

Any news on this?

@Daniel15

This comment has been minimized.

Show comment
Hide comment
@Daniel15

Daniel15 Mar 11, 2017

We switched from reprepro to Aptly for Yarn, and it works pretty well. I'd recommend it.

We switched from reprepro to Aptly for Yarn, and it works pretty well. I'd recommend it.

@chrislea

This comment has been minimized.

Show comment
Hide comment
@chrislea

chrislea Mar 11, 2017

Contributor

@Daniel15 Yes switching over to Aptly has been on my radar as a somewhat far-off TODO for quite some time, but unfortunately that change is non-trivial for us because of the overall impact to the workflow that it entails.

Additionally there is just a metric crapton of stuff out there that now expects our repos to behave as they currently do, and we'd definitely need to do whatever testing was needed to make sure that letting Aptly handle the repo management tasks wasn't going to make some unknown number of other things break in order to make pinning work.

I promise that we do understand the desire for this. As somebody that has Ubuntu running on a lot of my devices, it pains me personally that our rpm repos let people pick specific versions but our deb repos don't. It's just going to be a considerable amount of work to actually implement, which is not easy to carve out time for since a) we're a startup and thus very resource constrained and b) the demand for this change, while certainly relevant, just isn't that high.

So I don't have any great news to add to this issue, but I promise it's not something we've forgotten about either.

Contributor

chrislea commented Mar 11, 2017

@Daniel15 Yes switching over to Aptly has been on my radar as a somewhat far-off TODO for quite some time, but unfortunately that change is non-trivial for us because of the overall impact to the workflow that it entails.

Additionally there is just a metric crapton of stuff out there that now expects our repos to behave as they currently do, and we'd definitely need to do whatever testing was needed to make sure that letting Aptly handle the repo management tasks wasn't going to make some unknown number of other things break in order to make pinning work.

I promise that we do understand the desire for this. As somebody that has Ubuntu running on a lot of my devices, it pains me personally that our rpm repos let people pick specific versions but our deb repos don't. It's just going to be a considerable amount of work to actually implement, which is not easy to carve out time for since a) we're a startup and thus very resource constrained and b) the demand for this change, while certainly relevant, just isn't that high.

So I don't have any great news to add to this issue, but I promise it's not something we've forgotten about either.

@codyaray

This comment has been minimized.

Show comment
Hide comment
@codyaray

codyaray Mar 28, 2017

Yes, please please do this. My salt state fails everytime I run it until I manually update the version (which of course, we don't really want to do for every app every time).

Yes, please please do this. My salt state fails everytime I run it until I manually update the version (which of course, we don't really want to do for every app every time).

@chrislea

This comment has been minimized.

Show comment
Hide comment
@chrislea

chrislea Mar 28, 2017

Contributor

It is still on our list of things to look at @codyaray, but it's still not at a high priority.

Please keep in mind that for any LTS release, you're guaranteed that the APIs aren't going to change, and there are fairly frequent security related updates. So we really recommend always using the newest version of any LTS line that you're using, which is what apt or yum will do by default.

Contributor

chrislea commented Mar 28, 2017

It is still on our list of things to look at @codyaray, but it's still not at a high priority.

Please keep in mind that for any LTS release, you're guaranteed that the APIs aren't going to change, and there are fairly frequent security related updates. So we really recommend always using the newest version of any LTS line that you're using, which is what apt or yum will do by default.

@dgreene-r7

This comment has been minimized.

Show comment
Hide comment
@dgreene-r7

dgreene-r7 Mar 29, 2017

That's hopefully true regarding regressions, but sometimes they slip through. In an ideal world we could simply pin back the version of node we want to install rather than falling back to pulling deb artifacts directly from the pool.

dgreene-r7 commented Mar 29, 2017

That's hopefully true regarding regressions, but sometimes they slip through. In an ideal world we could simply pin back the version of node we want to install rather than falling back to pulling deb artifacts directly from the pool.

@jcputter

This comment has been minimized.

Show comment
Hide comment
@jcputter

jcputter Sep 14, 2017

cannot use this repo in production because of this....

cannot use this repo in production because of this....

@tardis4500

This comment has been minimized.

Show comment
Hide comment
@tardis4500

tardis4500 Sep 29, 2017

I agree with the previous comments that we are unable to use this in Production since we can go through an entire testing cycle in all our environments and then on Production deployment day, find out the install fails because it is no longer available.

I agree with the previous comments that we are unable to use this in Production since we can go through an entire testing cycle in all our environments and then on Production deployment day, find out the install fails because it is no longer available.

@luqasz

This comment has been minimized.

Show comment
Hide comment
@luqasz

luqasz Sep 30, 2017

I use LTS repo of node. I install it in testing and production. That is all I can do to minimize possible problems.

luqasz commented Sep 30, 2017

I use LTS repo of node. I install it in testing and production. That is all I can do to minimize possible problems.

Chrisdo82 pushed a commit to Chrisdo82/docker-java-node that referenced this issue Oct 18, 2017

Christian Dornbusch
changed specific versions of node to the latest ones
- due to nodejs we cannot pin to a specific version of Node.js (nodesource/distributions#33 (comment))
@metametadata

This comment has been minimized.

Show comment
Hide comment
@metametadata

metametadata Oct 19, 2017

I ended up pinning the version in my Dockefile by dowloading .deb file and apt-get install from it:

RUN set -ex \
  ; apt-get update \
  ; curl -o nodejs.deb https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/nodejs_8.7.0-1nodesource1_amd64.deb \
  ; apt-get install -y ./nodejs.deb \
  ; rm nodejs.deb \
  ; rm -rf /var/lib/apt/lists/*

I ended up pinning the version in my Dockefile by dowloading .deb file and apt-get install from it:

RUN set -ex \
  ; apt-get update \
  ; curl -o nodejs.deb https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/nodejs_8.7.0-1nodesource1_amd64.deb \
  ; apt-get install -y ./nodejs.deb \
  ; rm nodejs.deb \
  ; rm -rf /var/lib/apt/lists/*
@kundansmart501

This comment has been minimized.

Show comment
Hide comment
@kundansmart501

kundansmart501 Nov 6, 2017

wanted to update from version v0.10.25 to v6 on Ubuntu 14.0 , but able to do so

wanted to update from version v0.10.25 to v6 on Ubuntu 14.0 , but able to do so

@plinehan

This comment has been minimized.

Show comment
Hide comment
@plinehan

plinehan Jan 31, 2018

Thanks @metametadata! FWIW, I had to swap:

apt-get install -y ./nodejs.deb

for:

dpkg -i ./nodejs.deb

Otherwise, apt-get install spews a few thousand lines of:

E: Release 'nodejs.deb' for '$FOO' was not found

before failing. The dpkg command completed without reporting any missing dependencies.

plinehan commented Jan 31, 2018

Thanks @metametadata! FWIW, I had to swap:

apt-get install -y ./nodejs.deb

for:

dpkg -i ./nodejs.deb

Otherwise, apt-get install spews a few thousand lines of:

E: Release 'nodejs.deb' for '$FOO' was not found

before failing. The dpkg command completed without reporting any missing dependencies.

@hectcastro

This comment has been minimized.

Show comment
Hide comment
@hectcastro

hectcastro Feb 22, 2018

In addition to Aptly, packagecloud could help alleviate a bunch of the problems discussed here (and possibly others, because they support yum and are fronted by Fastly's CDN already). I'm obviously not familiar with your existing build pipeline, so I can't comment on the impact it'll have on that, but package publishing processes I've worked in the past with their CLI have been relatively painless.

In addition, I was partially part of a package repository migration process while at Basho. In that case, we put everything in packagecloud, made that the new source of truth in our docs, but kept the old setup running. Everything still worked the way people expected, but those who wanted in on the latest and greatest (or version pinning) had a clear path with packagecloud.

As for intermediate solutions to this problem, we've worked around it by pinning to Linux binary releases published on nodejs.org. Not as straightforward as a native operating system package, but usually better than compiling from source.

In addition to Aptly, packagecloud could help alleviate a bunch of the problems discussed here (and possibly others, because they support yum and are fronted by Fastly's CDN already). I'm obviously not familiar with your existing build pipeline, so I can't comment on the impact it'll have on that, but package publishing processes I've worked in the past with their CLI have been relatively painless.

In addition, I was partially part of a package repository migration process while at Basho. In that case, we put everything in packagecloud, made that the new source of truth in our docs, but kept the old setup running. Everything still worked the way people expected, but those who wanted in on the latest and greatest (or version pinning) had a clear path with packagecloud.

As for intermediate solutions to this problem, we've worked around it by pinning to Linux binary releases published on nodejs.org. Not as straightforward as a native operating system package, but usually better than compiling from source.

@unnawut unnawut referenced this issue in omisego/goban Mar 2, 2018

Merged

Add node and yarn to Goban's provisioning #5

@felixfbecker

This comment has been minimized.

Show comment
Hide comment
@felixfbecker

felixfbecker May 31, 2018

This is not just about using the latest version for security fixes, but about reproducible builds in general. Building the same Dockerfile twice in CI should be 100% guaranteed to work and result in the exact same image digest hash to hit the cache and not cause any pushes or redeploys. I can write a bot that does automatic PRs to update versions in a Dockerfile, I don't have to sacrifice build reproducibility just to stay up to date - as long as old versions are not deleted and can be pinned.

felixfbecker commented May 31, 2018

This is not just about using the latest version for security fixes, but about reproducible builds in general. Building the same Dockerfile twice in CI should be 100% guaranteed to work and result in the exact same image digest hash to hit the cache and not cause any pushes or redeploys. I can write a bot that does automatic PRs to update versions in a Dockerfile, I don't have to sacrifice build reproducibility just to stay up to date - as long as old versions are not deleted and can be pinned.

@ErisDS

This comment has been minimized.

Show comment
Hide comment
@ErisDS

ErisDS Jul 19, 2018

I thought that nodesource was the defacto place to install node from, but this limitation is 😳. It's not possible to use the ppa with configuration management tools, or anything designed to do repeatable builds - e.g. I ended up here because of this: saltstack-formulas/node-formula#22

Anyone else running into this - what did you do instead? I've fallen back to installing from source but it's so insanely slow I don't want to do this long term.

ErisDS commented Jul 19, 2018

I thought that nodesource was the defacto place to install node from, but this limitation is 😳. It's not possible to use the ppa with configuration management tools, or anything designed to do repeatable builds - e.g. I ended up here because of this: saltstack-formulas/node-formula#22

Anyone else running into this - what did you do instead? I've fallen back to installing from source but it's so insanely slow I don't want to do this long term.

@chrislea

This comment has been minimized.

Show comment
Hide comment
@chrislea

chrislea Jul 19, 2018

Contributor

@ErisDS You can always just grab specific packages directly from the repo using something like curl. Assuming you're interested in installing something from the 8.x release, you can find all the files here:

https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/

Hope this helps.

Contributor

chrislea commented Jul 19, 2018

@ErisDS You can always just grab specific packages directly from the repo using something like curl. Assuming you're interested in installing something from the 8.x release, you can find all the files here:

https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/

Hope this helps.

@tragiclifestories

This comment has been minimized.

Show comment
Hide comment
@tragiclifestories

tragiclifestories Jul 19, 2018

Yep, that's what we did in the end. I think there are fuller examples earlier in this thread or linked from it.

It's a fiddly, messy couple of lines in your CI config or dockerfile, but worse things happen at sea ...

Yep, that's what we did in the end. I think there are fuller examples earlier in this thread or linked from it.

It's a fiddly, messy couple of lines in your CI config or dockerfile, but worse things happen at sea ...

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