Closed c0d1ngm0nk3y closed 2 months ago
Tests are still missing: Reason that the current BuildFunc
is kind of hard to test and we didn't want to add any more parameters.
Idea: We would refactor BuildProcessResolver
to ProcessResolver
and instead of Resolve
, there would be ResolveBuildProcess
,ResolvePruneProcess
and ResolveUpdateNPMProcess
.
This would not only keep the BuildFunc
testable, but also simplify the signature by reming the need for the PruneProcess
.
@paketo-buildpacks/nodejs-maintainers WDYT?
Test failure related to https://github.com/paketo-buildpacks/npm-install/pull/689
@mhdawson We changed it to not install the global version. Hence we had to prepend
the .bin
to the PATH
instead of append
. Could you have another look?
Integration tests are failing, so I guess I have to make them run on ARM
:(
@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.
needs to be updated to 18
I have opened https://github.com/paketo-buildpacks/npm-install/pull/713 for this and picked the commit in the meantime.
The integration tests are driving me nuts. They are still failing for an unrelated reason. Seem that they are very fragile :(
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
The logger was fixed in packit
, we have to wait for a release > 2.14.0
to be released and consumed.
@c0d1ngm0nk3y thanks for the update.
@mhdawson Is there any way to get the ubi
extension run on arm
? Normally, I just skip the ubi
builder locally, but the current error in the tests only occur for ubi
.
When I run it locally, it fails with
[extender (build)] Resolving Node Engine version
[extender (build)] Node no longer requested by plan, satisfied by extension
[extender (build)] Setting up launch layer for environment variables
[extender (build)] Configuring build environment
[extender (build)] NODE_ENV -> "production"
[extender (build)] NODE_HOME -> ""
[extender (build)] NODE_OPTIONS -> "--use-openssl-ca"
[extender (build)] NODE_VERBOSE -> "false"
[extender (build)]
[extender (build)] Configuring launch environment
[extender (build)] NODE_ENV -> "production"
[extender (build)] NODE_HOME -> ""
[extender (build)] NODE_OPTIONS -> "--use-openssl-ca"
[extender (build)] NODE_VERBOSE -> "false"
[extender (build)]
[extender (build)] Writing exec.d/0-optimize-memory
[extender (build)] Calculates available memory based on container limits at launch time.
[extender (build)] Made available in the MEMORY_AVAILABLE environment variable.
[extender (build)] Writing exec.d/1-inspector
[extender (build)]
[extender (build)] Paketo Buildpack for NPM Install 1.2.3
[extender (build)] Resolving installation process
[extender (build)] Process inputs:
[extender (build)] node_modules -> "Found"
[extender (build)] npm-cache -> "Found"
[extender (build)] package-lock.json -> "Found"
[extender (build)]
[extender (build)] Selected NPM build process: 'npm ci'
[extender (build)]
[extender (build)] Executing launch environment install process
[extender (build)] Running 'npm ci --unsafe-perm --cache /layers/paketo-buildpacks_npm-install/npm-cache'
[extender (build)] npm ERR! code 1
Should the ubi
builder work with arm
?
@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?
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?
I am normally running them with the env variable DOCKER_DEFAULT_PLATFORM=linux/amd64
which seems to work fine. Also for the ubi
builder.
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.
I checked the posix standard
PATH
This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file. The prefixes shall be separated by a
(':'). If the pathname being sought contains no ('/') characters, and hence is a filename, the list shall be searched from beginning to end, applying the filename to each prefix and attempting to resolve the resulting pathname (see 4.16 Pathname Resolution ), until an executable file with appropriate execution permissions is found. When a non-zero-length prefix is applied to this filename, a shall be inserted between the prefix and the filename if the prefix did not end in . A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent characters ("::"), as an initial preceding the rest of the list, or as a trailing following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH . If the pathname being sought contains any characters, the search through the path prefixes shall not be performed and the pathname shall be resolved as described in 4.16 Pathname Resolution . If PATH is unset or is set to null, or if a path prefix in PATH contains a character ('%'), the path search is implementation-defined.
ubi
does it a bit differently and also accepts binaries, but to make it compatible I guess the approach with the extra directory containing only the npm
binary was needed.
@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 .bin_local
is only created if BP_NPM_VERSION
is set and adding a non-existing path to PATH
should not have any influence.
All checks have passed
Fixes https://github.com/paketo-buildpacks/nodejs/issues/270
based on https://github.com/paketo-buildpacks/npm-install/pull/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 https://github.com/paketo-buildpacks/nodejs/issues/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