opencontainers
Update GitHub Actions CI packages and command
Issue
N/A
Description
This change updates GitHub Actions packages actions/checkout to v4, actions/setup-go to v5, and actions/upload-artifacts to v4 to resolve NodeJS 16 deprecation warnings. It also updates GitHub Actions set-output command which is also deprecated.
Testing
CI passes without deprecation warnings
Additional references
- https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
- https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/
Need to verify changes to release workflow. Will try to have an update by 2/13.
Hi, this needs to be merged soon, the distribution-spec action currently auto fails:
Download action repository 'opencontainers/[email protected]' (SHA:0f98d91a0afe7ed3ab0f29349beed2bb4ba1507d)
Getting action download info
Error: This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: 0b7f8abb1508181956e8e162db84b466c27e18ce`. Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/
I don't believe it will be possible to fix opencontainers/[email protected] since that's a tagged release. This would need a merged fix and then a new release (v1.1.1) if external workflows are breaking.
I don't believe it will be possible to fix
opencontainers/[email protected]since that's a tagged release. This would need a merged fix and then a new release (v1.1.1) if external workflows are breaking.
This is probably a compelling argument for adjusting the action to take version as a parameter and pointing users at HEAD instead of a tag. 🤔
This is probably a compelling argument for adjusting the action to take version as a parameter and pointing users at HEAD instead of a tag. 🤔
I could see moving the conformance tests to a separate repo that is versioned independently (with the spec version being passed as a parameter as you suggest). That would allow development of the conformance tests, without the risk of breaking end users on every merge. Potentially that could be done with oci-conformance, separating the conformance tests added to the main branch, from the submissions in a doc branch.
That's a bigger change than I'm ready to bite off right now. I'll start with passing the spec version to a redesign of the conformance tests that I'm working on.