build(deps): bump actions/download-artifact from 3.0.0 to 3.0.1

[dependabot]

Bumps actions/download-artifact from 3.0.0 to 3.0.1.

Release notes

Sourced from actions/download-artifact's releases.

v3.0.1

• Bump @​actions/core to 1.10.0

Commits

• 9782bd6 Update @​actions/core to 1.10.0 (#178)
• 076f0f7 Merge pull request #156 from actions/dependabot/npm_and_yarn/ansi-regex-4.1.1
• 7151be3 Bump ansi-regex from 4.1.0 to 4.1.1
• 51cbdc4 Merge pull request #152 from actions/dependabot/npm_and_yarn/minimist-1.2.6
• e89a529 Bump minimist from 1.2.5 to 1.2.6
• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[kaworu]

CI build failure seems unrelated to the patch:

addgroup: gid '123' in use

% docker run -it  --rm docker.io/library/golang:1.19.3-alpine3.16 /bin/grep :123: /etc/group
ntp:x:123:

According to some recent sources, the GitHub action runner gid should be 121 so that could explain why we didn't hit this issue previously, but here it's 123 (for this run at least). See #751 for more context about why we need to map the uid/gid inside the docker container building the release.

Should we write a script running addgroup/adduser conditionally (i.e. when the gid respectively doesn't already exists)? cc @gandro

[gandro]

Should we write a script running addgroup/adduser conditionally (i.e. when the gid respectively doesn't already exists)? cc @gandro

We'd also need to run the command with the release gid. In the end, trying to reuse the host uid/gid is a bit fragile. Maybe we could use some form user-mapping instead?

[michi-covalent]

in tetragon repo we ended up doing cilium/tetragon#557

[gandro]

in tetragon repo we ended up doing cilium/tetragon#557

Not sure I understand this: If you assign a random uid/gid to the release user, it won't match the uid/gid of the user invoking the Makefile. I guess it fixes the issue where git complains that it's running as root, but it won't fix the issue where the Makefile caller won't be the owner of the generated release artifacts.

[gandro]

@dependabot rebase

[gandro]

Addressed the failing workflow in #821

[kkourt]

in tetragon repo we ended up doing cilium/tetragon#557

Not sure I understand this: If you assign a random uid/gid to the release user, it won't match the uid/gid of the user invoking the Makefile. I guess it fixes the issue where git complains that it's running as root, but it won't fix the issue where the Makefile caller won't be the owner of the generated release artifacts.

@gandro yap, I think we need to use settpriv (was not aware of it) in teragon as well.
Thanks!