-
Notifications
You must be signed in to change notification settings - Fork 17
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
Allow custom version of npm
#688
Conversation
8b49ded
to
635ccec
Compare
635ccec
to
18530da
Compare
Tests are still missing: Reason that the current Idea: We would refactor This would not only keep the @paketo-buildpacks/nodejs-maintainers WDYT? |
Test failure related to #689 |
build.go
Outdated
logger.Process("Checking custom npm version") | ||
npmVersion, found := environment.Lookup("BP_NPM_VERSION") | ||
if found { | ||
args := []string{"install", "-g", fmt.Sprintf("npm@%s", npmVersion)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@c0d1ngm0nk3y do you know where all the globall installed npm version later used? I know there are some cases where a global install has issues on linux install and I'm wondering if it can be installed non-global and then either direct paths or path search order can be used to get the installed non-global version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We changed it to a non global version
18530da
to
ad8e9b9
Compare
ad8e9b9
to
ef52a74
Compare
@mhdawson We changed it to not install the global version. Hence we had to |
Integration tests are failing, so I guess I have to make them run on |
build.go
Outdated
@@ -79,6 +82,24 @@ func Build(entryResolver EntryResolver, | |||
return packit.BuildResult{}, err | |||
} | |||
|
|||
logger.Process("Checking custom npm version") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should move this into the if found, and log something like "Using a custom npm versions set with BP_NPM_VERSION"
That would reduce the updates needed to the tests, both in this repo but more importantly in my mind possibly to tests which existing in the other buildpack repos.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principal, I find it a bit worrying that you should not add a log message because it can break tests. Those tests are way to fragile anyway. But you have a point and probably the log message is better suited in the if anyway.
@c0d1ngm0nk3y made one suggestion otherwise it looks good to me. |
I think some of the failures were related to the removal of support for 16.x, restarted the tests, although it might need a rebase to pick up the change I landed today for that. |
@c0d1ngm0nk3y actually this was not one of the repos where I saw a failure and fixed. If you search for 16 in the tests and replace with 18 that may fix up some of the test failures. Across a number of the repos the tests were coded to request Node.js 16 and since that was removed from node-engine the request needs to be updated to 18. |
a05b703
to
1a8e569
Compare
I have opened #713 for this and picked the commit in the meantime. |
1a8e569
to
b1160e3
Compare
The integration tests are driving me nuts. They are still failing for an unrelated reason. Seem that they are very fragile :( |
I think this error is due to too many requests on the github registry for fetching the buildpack images. Try rerunning them after 10-20 minutes |
499da6c
to
edc677a
Compare
build.go
Outdated
@@ -155,7 +176,7 @@ func Build(entryResolver EntryResolver, | |||
layer.BuildEnv.Default("NPM_CONFIG_GLOBALCONFIG", globalNpmrcPath) | |||
} | |||
path := filepath.Join(layer.Path, "node_modules", ".bin") | |||
layer.BuildEnv.Append("PATH", path, string(os.PathListSeparator)) | |||
layer.BuildEnv.Prepend("PATH", path, string(os.PathListSeparator)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still wondering a bit about this part of the change. With the append, installed packages could add a binary but not replace one of the system ones. With Prepend they can replace system ones which might be a security concern.
I assume it would be possible to pre-pend just npm, with something like
path := filepath.Join(layer.Path, "node_modules", ".bin")
layer.BuildEnv.Prepend("PATH", filepath.Join(path, "npm"), path, string(os.PathListSeparator))
layer.BuildEnv.Append("PATH", path, string(os.PathListSeparator))
which would still let us use the newer npm, but not change anything else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I will adapt it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which would still let us use the newer npm, but not change anything else
I did the change like proposed, but now many integration test fail. Only prepend
seem to be used and not the combination of prepend
and append
. Is there a reason why not both can be used at the same time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you post the code you tried? I don't see any reason why it should not be possible to do both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a look and there is is a bug in packit
(see code). It should work and "only" the logs are wrong, but I guess it is still worth fixing in packit
first.
The problem is that the log emitter
assumes that an environment variable is either prepended or appended. Not both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposed fix: paketo-buildpacks/packit#581
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@c0d1ngm0nk3y thanks for chasing that down.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still wondering a bit about this part of the change. With the append, installed packages could add a binary but not replace one of the system ones. With Prepend they can replace system ones which might be a security concern.
I assume it would be possible to pre-pend just npm, with something like
path := filepath.Join(layer.Path, "node_modules", ".bin") layer.BuildEnv.Prepend("PATH", filepath.Join(path, "npm"), path, string(os.PathListSeparator)) layer.BuildEnv.Append("PATH", path, string(os.PathListSeparator))
which would still let us use the newer npm, but not change anything else?
We ran into a problem with that one. It worked for ubi
, but the shell of the paketo-builder doesn't like binaries in the PATH
, only directories. So we created a folder containing only a symlink to npm
(unfortunately one more symlink) and prepended this folder to PATH
. WDYT?
edc677a
to
95f8714
Compare
The logger was fixed in |
@c0d1ngm0nk3y thanks for the update. |
26d6f61
to
99ee0f5
Compare
@mhdawson Is there any way to get the When I run it locally, it fails with
Should the |
@c0d1ngm0nk3y introduction of arm support is new on some stacks and none of the buildpacks are built for arm either. So short answer is that I don't think any of the components for the Node.js buildpack support arm. There is no reason that if you build the buildpacks they would not build on arm, but you would have to build all of them. I'm surprised that you can run any of the tests with arm? Is it that you are trying to use a M based OSX machine? |
99ee0f5
to
c1d851a
Compare
I am normally running them with the env variable |
c1d851a
to
66063e7
Compare
The tests are fine locally... |
@mhdawson It was "only" the node dependencies which could not be downloaded. I have the same problem locally from time to time. Seems not to be too reliable. |
Co-authored-by: Ralf Pannemans <[email protected]> Co-authored-by: Pavel Busko <[email protected]>
Co-authored-by: Ralf Pannemans <[email protected]>
Co-authored-by: Ralf Pannemans <[email protected]>
Co-authored-by: Ralf Pannemans <[email protected]>
Co-authored-by: Ralf Pannemans <[email protected]>
61fc834
to
50aee96
Compare
I checked the posix standard
|
@paketo-buildpacks/nodejs-maintainers Is there any chance to get this merged? Or is there anything missing? I checked again and there should be no possibility for any regression since the folder
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Fixes paketo-buildpacks/nodejs#270
based on #752
Summary
Instead of always using the
npm
installed by thenode-engine
buildpack, the user can specifyBP_NPM_VERSION
to change to the specified version.Use Cases
See paketo-buildpacks/nodejs#270 for details, but this allows users to use a specific version of
npm
rather than the one packaged withnodejs
, e.g. in case of a known bug.Details
If
BP_NPM_VERSION
is provided, it will install this version ofnpm
first before installing thenode_modules
. It will be installed withinnode_modules
(NOT globally).Unfortunately, there are shells that do not allow binaries to the
PATH
, but only directories. So in order to only prepend this specific binary (see comment), we have to create a separate folder.bin_local
and symlink thenpm
binary from.bin
. So that.bin_local
can be prepended toPATH
in order to use it instead of the already installednpm
. In order to make it accessible, itPATH
env of the current process, so that the followingnpm
call (e.g.npm install
) will use this instead.PATH
in theBuildEnv
, so that other buildpacks use the samenpm
PATH
in theLaunchEnv
, so that other usingnpm
at launch will use the same version.Checklist