ci: Update Github Actions for Node 20.

[philipaconrad]

This PR updates the upload-artifact and download-artifact Github actions to the latest version (v4), which should eliminate the deprecation warning spam we're seeing in CI.

Screenshot of an older CI run's warnings (non-exhaustive)

Note to reviewers: The release (post-tag) and post-merge workflows have been updated as well, with the same general strategies used for the more complex pull-request workflow.

[philipaconrad]

Ah, too late, didn't read: apparently, updating the upload-artifacts action to v4 introduces breaking changes to the behavior of uploading multiple times to the same artifact target. 🤦

The fix will be reworking the actions jobs to target unique artifact names/paths, but I or someone else will need to do some digging to make sure we don't break anything in silly ways from changing artifacts names around.

[srenatus]

See also #6650 😉

[ashutosh-narkar]

@philipaconrad we can do this in stages I think. We can fix the pull request workflow as that should not be affected by this. We can then look into the others which may need some reworking.

[philipaconrad]

So! The good news is that splitting the artifacts targets up by their OS/arch target in the build matrix should be just fine. It will mean that we will have a number of binaries targets equal to the number of arches. 🤔

[netlify]

✅ Deploy Preview for openpolicyagent ready!

Name	Link
🔨 Latest commit	4db599a
🔍 Latest deploy log	https://app.netlify.com/sites/openpolicyagent/deploys/661d4002445b030008001239
😎 Deploy Preview	https://deploy-preview-6670--openpolicyagent.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[philipaconrad]

Github Actions is annoying because you basically always have to test-by-running. 😅

At any rate, I've whacked the pull-request.yaml workflow into shape for the v4 update. We'll likely need to update the release actions as well, unless those do their own Go builds for the release artifacts.

Major changes:

• Unique artifact targets for each OS + Arch combination (ex: binaries-darwin-arm64, binaries-linux-amd64)
• GO_TAGS variants have a different name prefix: binaries-variant-{...}
  • To get all normal build targets, download-artifacts@v4 jobs can use the property: pattern: binaries-*
  • To get just the variant build targets, pattern: binaries-variant-*

I'm also adding a few comments here and there to document weirdness in the build system as it's come up (such as only smoke-testing amd64 targets, for instance).

To properly test the post-*.yaml actions, I'll need to get careful review of those files + we'll need to cut 1+ patch releases to exercise the jobs, once they're ready. 😅

[srenatus]

Oh cool

[johanfylling]

Thanks! 👍

[johanfylling]

Since this also contains arm64, it would have been nice if we could use all or something. But I suppose that would mess up the GOARCH env var ..

Perhaps we could do a third Upload Binaries step to handle the case where arch is empty 🤔.

This is very much a nit, so feel free to disregard 😄.

[philipaconrad]

In the interest of getting this merged, it may be worth adding a comment for that target about the situation, leaving the arch: amd64 field alone for now. 🤔

[srenatus]

This PR will never be green because the names of two required steps have changed:

↕️

So let's merge it and adjust the branch settings afterwards.

[johanfylling]

Yes, I was thinking the same @srenatus 👍 .
All open PRs would then need to be synced with main.

[anderseknert]

should this be named opa_no_oci like it is above? or are they just confusingly similar? :D

[philipaconrad]

So, the go_tags item in YAML is actually the whole string GO_TAGS="-tags=opa_no_oci", which is horrendous for downstream steps that expect just [a-zA-Z0-9_-]* as the expected character set. 😅 I took the lazy route, and added a new YAML item with just the important bits.

[anderseknert]

Right, but I meant that there’s a typo, or no? “ci” -> “oci”

[philipaconrad]

Thank you all for the review comments! 😄

I've updated the post-tag and post-merge workflows to use the same general naming strategy for uploads (binaries-<something...>) and the same download strategy for grouping published artifacts.

Those two workflows are noticeably less complex in how they partition the build jobs up, so they were much easier to refactor. Note that I cannot really test them, because they fire after major actions, like a PR merge or release tag, occur.

After this PR merges, I'll keep an eye on the GH actions to make sure I didn't b0rk the merge job. If it fails, then the post-tag action will fail almost identically.

[philipaconrad]

Also, for the 2x lingering status checks, see @srenatus's comment.