Skip to content
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

Update actions/upload-artifact to @v4 #1969

Merged

Conversation

cary-ilm
Copy link
Member

This requires all artifacts to have unique names, so the install_manifest.txt files need to uploaded with the name that includes the os and build number.

This requires all artifacts to have unique names, so the
install_manifest.txt files need to uploaded with the name that
includes the os and build number.

Signed-off-by: Cary Phillips <[email protected]>
Copy link
Contributor

@kdt3rd kdt3rd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@cary-ilm cary-ilm merged commit d8c96a0 into AcademySoftwareFoundation:main Jan 31, 2025
26 checks passed
@peterhillman
Copy link
Contributor

The CI on #1968 still fails on the OSS-fuzz test, which looks like it's still using upload-artifact v3. Does that need the same change?

@cary-ilm
Copy link
Member Author

cary-ilm commented Feb 1, 2025

Hmmm, yeah I missed that.

But since we have OSS-Fuzz, what would you say to just retiring the fuzz CI altogether? I don't see this workflow adding a lot of value.

@peterhillman
Copy link
Contributor

I would keep it going if that's not too much effort.
The ossfuzz_workflow within the OpenEXR CI should be catching PRs that would break OSS-Fuzz's testing, by compiling the PR and the oss-fuzz functions using the current oss-fuzz hosted build script

If a PR would cause the OSS-Fuzz project's build to fail, the build script would need to be updated before the PR is merged, otherwise we get an error report from OSS-Fuzz and testing stops. The oss_workflow would also need to pull the latest version of the build script for its own tests.

It's rather unlikely that the ossfuzz_workflow in the OpenEXR CI would discover a security vulnerability in the 5 minutes it runs, but it certainly should be able to check that the fuzzer still operates correctly.

@cary-ilm
Copy link
Member Author

cary-ilm commented Feb 1, 2025

OK, it's easy enough to fix, just chance the @sha to @v4. I'm away from my computer until tomorrow afternoon, I can submit a fix then if nobody does it first.

@kdt3rd
Copy link
Contributor

kdt3rd commented Feb 2, 2025

see #1970

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants