fix: upload-artifact and download-artifact v4#3312
fix: upload-artifact and download-artifact v4#3312laurentsimon merged 13 commits intoslsa-framework:mainfrom ramonpetgrave64:ramonpetgrave64-upload-download-artifact-v4
Conversation
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
This reverts commit 90909d4. Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
laurentsimon
left a comment
There was a problem hiding this comment.
LGTM. Had a comment on the workflow update
CHANGELOG.md
Outdated
|
|
||
| ### Unreleased: Breaking Change: upload-artifact and download-artifact | ||
|
|
||
| - Our workflows now use the new `@v4`s of `actions/upload-artifact` and `actions/download-artifact`, which are incompatiblle with the prior `@v3`. See Our docs on the [generic generator](./internal/builders/generic/README.md#compatibility-with-actionsdownload-artifact). |
There was a problem hiding this comment.
nit: Add a sentence (or a section) on how to upgrade from v2 to v3. I know it looks obvious, but let's call it out explicitly. (We can clean up the "how to upgrade" into. dedicated section when we do the release if needed) Wdut?
There was a problem hiding this comment.
I think you're right. A little bit of extra docs can go a long way. Added.
laurentsimon
left a comment
There was a problem hiding this comment.
Any reason you ad to update the package-lock.json? That should not be necessary. Maybe a leftover from prior experiments :)?
Just a package that had a vulnerability. I bumped the version with |
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
laurentsimon
left a comment
There was a problem hiding this comment.
LGTM, thanks1
Can we do the package json update in a separate PR to avoid "polluting" this PR's changes?
|
please check the linter warning |
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
|
@laurentsimon I removed the npm change and fixed the makrdownlint errors |
|
secure-upload-folder seems to be failing. can you take a look? |
|
Yes, it should fail because
|
Signed-off-by: laurentsimon <64505099+laurentsimon@users.noreply.github.com>
Got it. I created #3320 for tracking. Should be easy to fix. I'll disable the check temporarily to merge |
|
Any idea why |
This reverts commit b595e06.
This reverts commit b595e06.
Summary
Testing Process
This change is tested with our existing PR Check workflows that use both directly and indirectly call upload-artifact and download-artifact.
secure-upload-foldershould fail in this PR because it will usesecure-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