-
Notifications
You must be signed in to change notification settings - Fork 39
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
👻 force npm9 during image build #1781
Conversation
Ever since the build container we use [1] updated to use `npm@10`, the image builder github action has encountered a number of problems. The first was solved with konveyor#1746. The second more random problem has been with network connections erroring out when installing dependencies. To work around the network error, force the build to use `npm@9`. Alternative solutions: - Add the force to `npm@9`` directly in the Dockerfile for use in all circumstances - Use the `:1-88` version of the build container instead of `:latest` - Find a way to use something like verdaccio to proxy/mirror the npmjs repo during the build so npmjs fetches can be pooled across the parallel image builds [1] registry.access.redhat.com/ubi9/nodejs-18:latest Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
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.
Looks explicit enough for me:)
Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
Ever since the build container we use [1][2] updated to use `npm@10`, the image builder github action has encountered a number of problems. The first was solved with #1746. The second more random problem has been with network connections erroring out when installing dependencies. To work around the network and nofiles errors: 1. enforce the use of `npm@9` 2. pin the Dockerfile base images to specific version tags; builder at `:1-88`, and runtime at `:1-93` Additional solutions: - Add the force to `npm@9` directly in the Dockerfile for use in all circumstances - Find a way to use something like verdaccio to proxy/mirror the npmjs repo during the build so npmjs fetches can be pooled across the parallel image builds [1] registry.access.redhat.com/ubi9/nodejs-18:latest [2] https://catalog.redhat.com/software/containers/ubi9/nodejs-18/62e8e7ed22d1d3c2dfe2ca01 --------- Signed-off-by: Scott J Dickerson <sdickers@redhat.com> Signed-off-by: Cherry Picker <noreply@github.com>
Ever since the build container we use [1][2] updated to use `npm@10`, the image builder github action has encountered a number of problems. The first was solved with #1746. The second more random problem has been with network connections erroring out when installing dependencies. To work around the network and nofiles errors: 1. enforce the use of `npm@9` 2. pin the Dockerfile base images to specific version tags; builder at `:1-88`, and runtime at `:1-93` Additional solutions: - Add the force to `npm@9` directly in the Dockerfile for use in all circumstances - Find a way to use something like verdaccio to proxy/mirror the npmjs repo during the build so npmjs fetches can be pooled across the parallel image builds [1] registry.access.redhat.com/ubi9/nodejs-18:latest [2] https://catalog.redhat.com/software/containers/ubi9/nodejs-18/62e8e7ed22d1d3c2dfe2ca01 --------- Signed-off-by: Scott J Dickerson <sdickers@redhat.com> Signed-off-by: Cherry Picker <noreply@github.com> Signed-off-by: Scott J Dickerson <sdickers@redhat.com> Signed-off-by: Cherry Picker <noreply@github.com> Co-authored-by: Scott Dickerson <sdickers@redhat.com>
Looks like this is causing NPM install to fail locally. Error fixed by moving back to Error:
|
This was due to my local npm version falling outside the supported version range in package.json. Fixed with: |
Backport image build changes made on main and release-0.3 to get release-0.2 building properly. See: konveyor#1781, konveyor#1780 Follow-up to konveyor#1801, konveyor#1871 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
Backport image build changes made on main and release-0.3 to get release-0.2 building properly. See: konveyor#1781, konveyor#1780 Follow-up to konveyor#1801, konveyor#1871 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any `Dockerfile` change will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. In future, it may be reasonable to extend this check to happen when other core build related changes are made (package-lock.json, package.json). See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should show up most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should reveal most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See #1742, #1746, and #1781 for some other examples of when this check could have caught issues before a PR merge. Supports: #1883 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
…ange (konveyor#1907) If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should reveal most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Backport-of: konveyor#1907 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
…ange (konveyor#1907) If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should reveal most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See konveyor#1742, konveyor#1746, and konveyor#1781 for some other examples of when this check could have caught issues before a PR merge. Supports: konveyor#1883 Backport-of: konveyor#1907 Note: build architectures updated to match the settings on the backport target branch Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
…ange (#1907) (#1914) If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should reveal most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See #1742, #1746, and #1781 for some other examples of when this check could have caught issues before a PR merge. Supports: #1883 Backport-of: #1907 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
…ange (#1907) (#1915) If the workflow is run from a PR, and the PR includes a change to the `Dockerfile` or `package-lock.json`, then run image builds for all of our target platforms. The images are built but not pushed to any repository. We want to be reasonably sure that any major build file changes will not cause the image-build-and-push on PR merge workflow to break. Doing the image build here should reveal most problems much earlier. For example, a npm version update in the build container could break github action `nofiles` or network access capabilities for the npm install. See #1742, #1746, and #1781 for some other examples of when this check could have caught issues before a PR merge. Supports: #1883 Backport-of: #1907 Note: build architectures updated to match the settings on the backport target branch Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
Ever since the build container we use [1][2] updated to use
npm@10
, the image builder github action has encountered a number of problems. The first was solved with #1746. The second more random problem has been with network connections erroring out when installing dependencies.To work around the network and nofiles errors:
npm@9
:1-88
, and runtime at:1-93
Additional solutions:
npm@9
directly in the Dockerfile for use in all circumstances[1] registry.access.redhat.com/ubi9/nodejs-18:latest
[2] https://catalog.redhat.com/software/containers/ubi9/nodejs-18/62e8e7ed22d1d3c2dfe2ca01