• X
• Mastodon
• LinkedIn
• Facebook

operator/prebuilt.Dockerfile.dockerignore (1)

1-1: ⚠️ Potential issue | 🟠 Major

This Dockerfile-specific ignore file turns the ignore rules into a no-op.

For docker build -f prebuilt.Dockerfile .., Docker uses prebuilt.Dockerfile.dockerignore as the active ignore file rather than layering it on top of the repo-root .dockerignore. With only a ! rule here, nothing is excluded, so the whole repo gets sent as build context. That undercuts the CI speedup this PR is trying to get and can re-include paths the root ignore file normally keeps out. Please mirror the root ignore rules here (or drop the Dockerfile-specific file) before whitelisting bin/linux_*/stackrox-operator.

When both a root `.dockerignore` and a Dockerfile-specific file like `prebuilt.Dockerfile.dockerignore` exist, does Docker merge them or does the Dockerfile-specific file take precedence?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@operator/prebuilt.Dockerfile.dockerignore` at line 1, The
prebuilt.Dockerfile.dockerignore currently contains only the whitelist rule
`!/bin/linux_*/stackrox-operator`, which makes the file override the root
.dockerignore and sends the entire repo as build context; update
prebuilt.Dockerfile.dockerignore to either mirror the root .dockerignore
contents (copy all root ignore rules into this file) and then append the
whitelist line `!/bin/linux_*/stackrox-operator`, or remove
prebuilt.Dockerfile.dockerignore entirely so Docker uses the root .dockerignore;
ensure the final file includes the same exclusions as the repository root before
the whitelist is applied.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

.github/workflows/build.yaml (1)

674-678: Consider adding if: ${{ !cancelled() }} for consistency with build-and-push-main.

The build-and-push-main job (line 387) uses if: ${{ !cancelled() }} to allow partial matrix completion when some prerequisite jobs fail. This enables building images for architectures where prebuilds succeeded, even if others failed.

The build-and-push-operator job lacks this condition, meaning it will be entirely skipped if any pre-build-go-binaries matrix run fails—even for architectures where prebuilds succeeded.

If this asymmetry is intentional (e.g., stricter requirements for operator builds), this comment can be disregarded.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/build.yaml around lines 674 - 678, The
build-and-push-operator job lacks the cancellation guard present in
build-and-push-main; update the build-and-push-operator job declaration to
include the same condition by adding if: ${{ !cancelled() }} so the operator job
can proceed for matrix entries that completed even if other pre-build matrix
runs failed (apply this change to the job named build-and-push-operator to
mirror build-and-push-main).