-
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
🌱 Test image build when build related files change #1907
Conversation
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 <[email protected]>
Note: This PR should be backported to release-0.3 and release-0.4 to help protect the active release branches. Example of the action run against test PRs in my fork:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1907 +/- ##
==========================================
+ Coverage 39.20% 41.22% +2.02%
==========================================
Files 146 158 +12
Lines 4857 5189 +332
Branches 1164 1323 +159
==========================================
+ Hits 1904 2139 +235
+ Misses 2939 2931 -8
- Partials 14 119 +105
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Configure dependabot to create PRs when the images we use in the `Dockerfile` have a newer version. This allows us to reference specific container images and be automatically notified of newer versions. Supports: konveyor#1883 CI added in konveyor#1907 will run against the PRs dependabot will open for `Dockerfile` changes. This will allow us to have confidence that the update will be successful. Signed-off-by: Scott J Dickerson <[email protected]>
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.
VISACK. Good idea.
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 the future it would be nice to include this capability into konveyor/release-tools/.github/workflows/build-push-images.yaml@main
.
If you could document what you mean in an issue against the repo (because it isn't immediately obvious how I could put this into the reusable workflow in a way that benefits everyone) that would be supremely helpful to me. |
Configure dependabot to create PRs when the images we use in the `Dockerfile` have a newer version. This allows us to reference specific container images and be automatically notified of newer versions. Supports: #1883 CI added in #1907 will run against the PRs dependabot will open for `Dockerfile` changes. This will allow us to have confidence that the update will be successful. Signed-off-by: Scott J Dickerson <[email protected]>
…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 <[email protected]>
…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 <[email protected]>
…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 <[email protected]>
…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 <[email protected]>
If the workflow is run from a PR, and the PR includes a change to the
Dockerfile
orpackage-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