fix: Trivy download into dapper container is skipped

[holysoles]

Proposed Changes

When building k3s from source using dapper, trivy is not downloaded and the build fails when trivy attempts to be executed.

Each RUN statement is executed in its own shell environment, so TRIVY_ARCH is empty when checked in the following RUN.

Types of Changes

Bugfix for Dapper Dockerfile

Verification

Check that your go architecture (go env GOARCH) is one of the following: arm64, amd64, s390x

Then, follow the instructions in BUILDING.md:

git clone --depth 1 https://github.com/k3s-io/k3s.git
cd k3s
mkdir -p build/data && make download && make generate
make

Testing

This change is not covered by tests, as it is a build workflow.

Linked Issues

N/A

User-Facing Change

NONE

Further Comments

[dereknola]

This works just fine on amd64 and our CI runs on arm64 as well, what ARCH host are you running this on?

[holysoles]

@dereknola This came up while trying to compile for i386 on a amd64 host even after adding I added a TRIVY_ARCH case for 386. I wrongly assumed the same error would arise when running on a supported architecture since it was the same logic.

However while investigating it looks like there is another bug that causes trivy scans to get skipped for everything except 386. Just applied a fix in this commit. If you apply that patch to image_scan.sh for an officially supported architecture, then make will error out. Potentially of note, trivy does still appear to support a 32bit binary in their recent releases, but that's probably outside the scope of this fix.

Some additional inspection for amd64:

I inspected the Dapper image that gets generated with master checked out, with dive and it doesnt look like the binary gets added during that layer:

Empirical test:

# check env
go env GOARCH

docker build -t k3s-dapper:latest -f Dockerfile.dapper .
docker run -it --rm --entrypoint "" k3s-dapper:latest /bin/sh

# check for trivy inside container
docker run -it --rm --entrypoint "" k3s-dapper:latest which trivy
docker run -it --rm --entrypoint "" k3s-dapper:latest /usr/local/bin/trivy

[dereknola]

Excellent points. The Trivy download inside the Dockerfile.dapper is from legacy build systems that are not being exercised in our CI today. We don't call ./scripts/package-image in our CI, so we never call the scripts/image_scan.sh, it only exists for local development. Future work should likely be to rip out all usage of Trivy "internally" and just rely on newer GHA trivy workflows.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 19.92%. Comparing base (07171fd) to head (35d7896).
Report is 1 commits behind head on master.

❗ There is a different number of reports uploaded between BASE (07171fd) and HEAD (35d7896). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (07171fd)	HEAD (35d7896)
e2etests	1	0

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #12219       +/-   ##
===========================================
- Coverage   40.58%   19.92%   -20.67%     
===========================================
  Files         187      184        -3     
  Lines       19286    19221       -65     
===========================================
- Hits         7827     3829     -3998     
- Misses      10272    14961     +4689     
+ Partials     1187      431      -756     

Flag	Coverage Δ
e2etests	?
unittests	19.92% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[holysoles]

Pretty sure the CI jobs are failing since now trivy doesnt exist on the GHA runners.. Want me to instead just go ahead and do the work now to remove trivy references from Dapper and scripts/image_scan.sh?

Otherwise this is probably just best closed, doesnt seem worth altering the build job to have trivy available if that isnt the direction y'all are moving in.

[dereknola]

I'm not sure when the trivy removal will happen, so lets just take an easy way out for you and change the image_scan.sh to check if trivy command is found first before calling it. That way if it is still being used "somewhere" in the Drone CI, it doesn't break that.

[holysoles]

@dereknola should be set, let me know if you have any feedback!