[bug] (v4) Unable to upload to same artifact name from multiple jobs #478
Comments
|
Actually, it seems this is called out here:
It just wasn't included in the "What's changed" section of the Dependabot release notes because it just has a summary saying "Lots has changed". I should've followed the link through. Seems like this is certainly intended though. |
|
Well, this is a bad news for me. I find convenient to use the like in https://github.com/Neoteroi/BlackSheep/actions/runs/7370452109/job/20056867940 Now if I want to upgrade my workflow, I need to publish to different folders and download artifacts from multiple sources - making the workflow look like a mess compared to how clean it used to look like. For now I stay with |
|
Yeah, I rolled back to v3 too. Until I'm forced to upgrade, the old way is much more convenient for me. |
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 3 to 4. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v3...v4) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Possibly fixes actions/upload-artifact#478
Reverts #5830. It is breaking the release pipeline. actions/upload-artifact#478
|
I had to roll back also |
|
Same here, I also use a matrix to build multi platform releases in the same directory, and then zipping them all together, rolling back to v3 :( |
|
Seems like a lot of people have been bitten by this, so although it appears to have been deliberate I'm re-opening for better visibility to see if the authors want to chime in (of course, it's very possible it may just be closed as WAI). |
…a breaking change in actions/upload-artifact@v4 (see actions/upload-artifact#478)
v4 requires to have every uploaded artifact in a separate directory. - actions/upload-artifact#478 - https://github.com/actions/upload-artifact/blob/main/docs/MIGRATION.md
According to https://github.blog/changelog/2024-02-13-deprecation-notice-v1-and-v2-of-the-artifact-actions/ v2 is deprecated. Besides that the workflow doesn't work with v2 anoymore - https://github.com/JetBrains/compose-multiplatform/actions/runs/10794252433/job/29978381803?pr=5134 : > Error: This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: v2`. Learn more: https://github.blog/changelog/2024-02-13-deprecation-notice-v1-and-v2-of-the-artifact-actions/ The suggested version is v4. But it requires more changes to the workflow configuration (see actions/upload-artifact#478). Let's use v3 for now.
## Describe your changes Update our GitHub actions versions to fix the deprecation warning. With `actions/upload-artifact@v4`, multiple jobs cannot upload to the same folder anymore. Hence, I have updated the flows according to [this migration guide](https://github.com/actions/upload-artifact/blob/main/docs/MIGRATION.md#multiple-uploads-to-the-same-named-artifact). See also this discussion: actions/upload-artifact#478 The workflows for cypress are kept on `v3` according to [this comment](streamlit#8689 (review)) to keep the usage of it simple until we retire it soonish. ## GitHub Issue Link (if applicable) ## Testing Plan - if the CI workflows run through, we should be all good --- **Contribution License Agreement** By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.
|
@DanTup I feel this migration so ugly. Why it "just work" before, and now you need to do this strange shitty coding -_- |
|
@tvorogme I don't disagree, but this ship has sailed and I don't have any ability to improve it (I'm not a contributor here, I'm just a user that was affected by this change). |
Reverts onnx#5830. It is breaking the release pipeline. actions/upload-artifact#478 Signed-off-by: Linsho Kaku <linsho@preferred.jp>
It was failing with: Error: This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: v2`. Learn more: https://github.blog/changelog/2024-02-13-deprecation-notice-v1-and-v2-of-the-artifact-actions/ Upgrading directly to 'v4' isn't straightforward, given it includes breaking changes[1]. Instead of uploading the whole folder, files are uploaded individually and then downloaded together. [1]: actions/upload-artifact#478
GitHub did something stupid on v4 that we'd need to overhaul the workflow in the near future. actions/upload-artifact#478 Roll back to v3 for now.
GitHub did something stupid on v4 that we'd need to overhaul the workflow in the near future. actions/upload-artifact#478 Roll back to v3 for now.
upload-artifact v4 is broken for systems using matrix of versions. See actions/upload-artifact#478
Fix upload artifacts actions/upload-artifact#478 (comment)
…12 to version 2.3.1
Lars Holmberg (8):
update versioning comments
Bump version to 2.1.1
publish workflow: publish source package only once the binary builds have succeeded (so we're more confident that it will work and we wont publish source and no binaries)
Bump version to 2.2.0
Downgrade artifact actions due to actions/upload-artifact#478
GH actions: Use more specific job names
GH actions: use kebab-case (snake_case is deprecated and gives a warning)
Bump version to 2.3.1
Michael (4):
Drop support for outdated python and gevent versions (#192)
Further spring cleaning (#195)
Fix publishing build issue (#201)
Fixes http.client patching (#200)
Michael Löffler (39):
Fix SSL deprecation warnings
Add .venv config to gitignore
Testcases now use only one localhost:54323 for tests and not a whole zoo anymore
Renamed pytest marker online to network as suggested in #189
Fixes #142
Redo code duplication to avoid import issues from other tests
Upgrade llhttp v6.0.11
Removed restkit benchmark as it seems discontinued
Updated github actions for publish.yml
Removed outdated test version forks
Use pytest tmp_path for handling temporary files
Fix cookilib compat testcase
Parametrized some more tests; removed __main__ sections
Updated benchmarks and results
Removed restkit compatible useragent as of restkit deprecation
Added useragent download testcase; improved download examples
Rerun benchmarks without monkeypatching, which seems to slow down the other http clients
Make httpbin host configurable; improve client tests; regroup network dependent tests; fix flaky httpbin test
Switch to httpbingo.org as httpbin endpoint for better test reliability
Fix link to benchmarks readme
Make headers preserve the case even for headers with duplicate field names
URL refactoring: left all the parsing to the trustworthy hands of the std lib
Improve SSL tests
Move common test mockup to conftest.py
Move ClientPool back to httplib2
Make max_retries and max_redirects not count the initial attempt
Fixes #202 using test.pypi.org before publishing
Add MIT license classifier
Move license note about previous http parser to README.md
Bump version to 2.2.1
Clean up readme and example code
Fixes #179
Add a thin requests compatibility layer
Fix some warnings on parser build
Restructure folders, so that tests don't need to be included in the package and still can import from each other
Move tox config into pyproject.toml
Run codespell
Add requests API compatibility in README
Fix locust backwards compatibility
|
So, what is the actual fix ? We must update to @v4 until 30 Nov. |
|
@georgik98, that works. My post and mentioned comment. We've switched to the v4 for download/upload actions and slightly adjusted workflow. |
and others
(Edit: There are solutions posted in this thread such as at #478 (comment), #478 (comment), #478 (comment))
What happened?
The PR from dependabot to upgrade to v4 is failing on my project with this error:
It seems like this is a breaking change that wasn't mentioned in the changelog and I'm not sure if it was deliberate.
There's some discussion about this behaviour in #279 and it suggests that it was fine to do this and there wouldn't be issues as long as the filenames within the artifact are unique. This was convenient to bundle the logs from several shards together into a single artifact rather than having lots of individual zip files to download.
What did you expect to happen?
I expected everything to work the same as in v3 unless it was noted as a deliberate breaking change.
How can we reproduce it?
Create multiple jobs that upload artifacts with the same name (but the files from each job are uniquely named).
Anything else we need to know?
No response
What version of the action are you using?
v4.0.0
What are your runner environments?
linux, window, macos
Are you on GitHub Enterprise Server? If so, what version?
No response
The text was updated successfully, but these errors were encountered: