Skip to content
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

Enable dependabot tracking and add CI tests for the Dockerfile #1883

Closed
sjd78 opened this issue Apr 24, 2024 · 2 comments · Fixed by #1907 or #1908
Closed

Enable dependabot tracking and add CI tests for the Dockerfile #1883

sjd78 opened this issue Apr 24, 2024 · 2 comments · Fixed by #1907 or #1908
Assignees
Labels
kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/normal Higher priority than priority/minor. Nice to have. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Milestone

Comments

@sjd78
Copy link
Member

sjd78 commented Apr 24, 2024

Since using the :latest label on the build and run time base images in the Dockerfile is dangerous (see #1746 and #1781), being able to use a specific tested version of the images is important. Dependabot support tracking the images in use in a Dockerfile and creating a PR when never versions are available. Also, since sometimes a problem with the build doesn't surface until the on-merge actions are run, CI specifically for the Dockerfile should be implemented.

Things to do:

  • Enable dependabot on the Dockerfile. Multiple ecosystems are allowed in the config, so this style is allowable:
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    allow:
      - dependency-name: "@patternfly/*"
        dependency-type: "direct"

  - package-ecosystem: docker
    directory: "/"
    schedule:
      interval: daily
  • Based on the on-merge workflow image-build.yaml that builds the images and uploads to a repo, create an action:
    • If the Dockerfile has been touched, execute. Else, skip.
    • Run the image build with the same settings as the multiarch build, but don't push to a repo
    • Pass CI on a Dockerfile change when the image builds all successfully complete (in the github action environment)
@konveyor-ci-bot
Copy link

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

@konveyor-ci-bot konveyor-ci-bot bot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-kind Indicates an issue or PR lacks a `kind/foo` label and requires one. needs-priority Indicates an issue or PR lacks a `priority/foo` label and requires one. labels Apr 24, 2024
@sjd78 sjd78 added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/normal Higher priority than priority/minor. Nice to have. triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-kind Indicates an issue or PR lacks a `kind/foo` label and requires one. needs-priority Indicates an issue or PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Apr 29, 2024
sjd78 added a commit to sjd78/tackle2-ui that referenced this issue 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 issue 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 issue 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 issue 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 issue 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 issue 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 issue 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 issue 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 issue 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 issue 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 issue 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 issue May 10, 2024
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 <sdickers@redhat.com>
@sjd78
Copy link
Member Author

sjd78 commented May 10, 2024

Part 1 implemented in #1908
Part 2 implemented in #1907

@sjd78 sjd78 self-assigned this May 10, 2024
sjd78 added a commit to sjd78/tackle2-ui that referenced this issue 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 issue 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 that referenced this issue May 14, 2024
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 <sdickers@redhat.com>
sjd78 added a commit to sjd78/tackle2-ui that referenced this issue 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 issue 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 sjd78 added this to the v0.5.0 milestone May 15, 2024
sjd78 added a commit that referenced this issue 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 issue 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
Labels
kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/normal Higher priority than priority/minor. Nice to have. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
Status: ✅ Done
1 participant