🌱 Increase ulimit nofiles on image-build.yaml #1746
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Builds keep failing with EMFILE errors, so follow the advice from a similar issue work around: npm/cli#4783 (comment) Signed-off-by: Scott Dickerson <sdickers@redhat.com>
sjd78
changed the title
fix typo Signed-off-by: Scott Dickerson <sdickers@redhat.com>
|
The multiarch build with this nofiles change works great on my fork: https://github.com/sjd78/tackle2-ui/actions/runs/8174501095 (or at least it does if npm install doesn't start timing out / get rate limited) |
|
Still hitting the error today on merge to main: https://github.com/konveyor/tackle2-ui/actions/runs/8175674051/job/22353327517#step:7:71 |
|
Another followup -- The Running the build locally with podman will encounter the EMFILE error without adding Running the build with the previous image release |
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
Mar 14, 2024
Apply github actions changes to the release-0.3 branch: - konveyor#1759 - konveyor#1746 Signed-off-by: Scott J Dickerson <sdickers@redhat.com>
ibolton336
added a commit
that referenced
this pull request
Mar 15, 2024
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
Mar 16, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
Mar 19, 2024
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>
sjd78
added a commit
that referenced
this pull request
Mar 19, 2024
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>
github-actions bot
pushed a commit
that referenced
this pull request
Mar 19, 2024
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>
sjd78
added a commit
that referenced
this pull request
Mar 19, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 10, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 13, 2024
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>
sjd78
added a commit
that referenced
this pull request
May 14, 2024
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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 15, 2024
…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>
sjd78
added a commit
to sjd78/tackle2-ui
that referenced
this pull request
May 15, 2024
…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>
sjd78
added a commit
that referenced
this pull request
May 15, 2024
…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>
sjd78
added a commit
that referenced
this pull request
May 15, 2024
…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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Builds keep failing with EMFILE errors, so follow the advice from a similar issue work around: npm/cli#4783 (comment)