-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] Use upload-artifact v4 #3068
Comments
upload-artifact@v4+ also is not yet available for GHES, so v3 should definitely be kept as the default version. |
I think it makes more sense to release a new version of the generator that is compatible with v4 by default (as soon as possible to avoid breaking pipelines that have already updated I would argue that this release would have a breaking change. So the release version should be The changelog and documentation should warn about the compatibility issue and that users should use |
Am I right in understanding that upload/download-artifact |
Yes, you're right. See actions/download-artifact#250 (comment). |
Got it. Thanks.
I agree about the compatibility and version number but is an option really necessary? In what situation do you think users would need to use it? I expect that it's not a huge deal to upgrade to |
As @jkreileder pointed out |
I'm not sure how hosted runners work on GHES. Are hosted runners supported or do users need to use self-hosted runners? |
Yes, GitHub Enterprise supports standard GitHub-hosted runners. |
I think that's Github Enterprise Cloud which supports hosted runners (as it's hosted by Github) vs Github Enterprise Server which doesn't support hosted runners (as it's self-hosted). I may be showing my ignorance though. I'm not super familiar with Github Enterprise offerings. |
@ianlewis you're right, GHES only supports self-hosted runners. |
This is currently labeled feature, but I think its closer to a bug, in that its breakage for new users trying to use the generator workflow, as happened to me yesterday, or extant users dealing with an update to artifact actions. also fwiw having also done the dependabot driven update from v3 to v4 on artifact actions, it does have some nuance/work for projects potentially based on usage wrt to immutable cache names. [update] - fwiw, gh cli does seem to be able to retrieve assets uploaded with either v3 or v4 re end user workarounds. |
@behnazh-w I'm not sure if maintaining two versions would be too much work: The only difference between slsa-github-generator@v1 and slsa-github-generator@v2 would be the dependency on the up/download-artifact version - 10 lines of yaml code if I counted correctly. For users that would mean:
|
@jkreileder I was wrongly thinking of the Github Enterprise Cloud when I proposed to have backward compatibility with GHES earlier. I don't think slsa-github-generator supports self-hosted runners needed by GHES anyway. So, we might not need backward-compatibility altogether? @laurentsimon @ianlewis please correct me if I'm wrong. |
Yes. That was my thinking. |
…v3 (#686) The provenance generator GitHub Action `slsa-framework/generator_generic_slsa3.yml` is not compatible with `actions/download-artifact@v4` yet. We need to make sure these two Actions and `actions/upload-artifact` are all compatible. This PR reverts `actions/download-artifact` and `actions/upload-artifact` GitHub Actions to v3. We will update them to v4 when the next version of `generator_generic_slsa3.yml` that will be compatible with `actions/download-artifact@v4` is released. See this relevant `slsa-framework/slsa-github-generator#3068`.
This also seems to be an issue regarding the deprecation of Node 16. The v3 versions of
|
We're working on this for next release. Given the comments above, we're going to do a major release that will only support v4 upload / download Action. |
# Summary - Fixes #3068 to use upload-artifact and download-artifact v4 - following up in slsa-framework/example-package#336 ## Testing Process This change is tested with our existing PR Check workflows that use both directly and indirectly call upload-artifact and download-artifact. - One test for `secure-upload-folder` should fail in this PR because it will use `secure-upload-artifact@main`. There's no workaround to dynamically use the PR's ref instead of `@main`, but after merging this PR, the test should start passing. ## Checklist - [x] Review the contributing [guidelines](./../CONTRIBUTING.md) - [x] Add a reference to related issues in the PR description. - [x] Update documentation if applicable. - [x] Add unit tests if applicable. - [x] Add changes to the [CHANGELOG](./../CHANGELOG.md) if applicable. --------- Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com> Signed-off-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com> Co-authored-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com>
we may need a compatibility option as argument to avoid breaking folks who currently use v3
The text was updated successfully, but these errors were encountered: