[bug] breaking change in V4: artifact of the same name cannot be uploaded

[liqunfu]

What happened?

We have an upload task in our release actions like this:
https://github.com/onnx/onnx/blob/8a782415a69faf626abc032ff6b2a16187e13c4f/.github/workflows/release_win.yml#L85
uses: a8a3f3a # v3.1.3
with:
name: wheels
path: ./onnx/dist

name of the artifact, "wheels", is fixed.
With V4 we get this failure:
Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

To require artifact name being unique does not make any sense in our case. There are other complaints for the same issue (#478)
Please remove this requirement. At this moment we have to stay away from V4 (onnx/onnx#5845).

What did you expect to happen?

artifact of the same name shall be able to be uploaded

How can we reproduce it?

as an example:
https://github.com/onnx/onnx/actions/workflows/release_linux_x86_64.yml

Anything else we need to know?

No response

What version of the action are you using?

artifact@c7d193f32edcb7bfad88892161225aeda64e9392 # v4.0.0

What are your runner environments?

linux, window, macos

Are you on GitHub Enterprise Server? If so, what version?

No response

[ptr727]

Same here, had to revert to v3 as I use a matrix and add artifacts to the same folder.
Also reported #478 that was closed because it was documented, but without an alternative I'll find an alternative action that allows matrix operations to create artifacts in the same folder.

I did find the https://github.com/actions/download-artifact/blob/main/docs/MIGRATION.md file with some hints, I used the suggested method of using unique names from the matrix to the same folder, then using pattern instead of name and merging the artifacts on download, seems to work.

[DanTup]

I just re-opened #478 without seeing this issue. I guess they are the same. The one one has more references to it, so maybe this one should be closed as a dupe of #478?

[liqunfu]

I just re-opened #478 without seeing this issue. I guess they are the same. The one one has more references to it, so maybe this one should be closed as a dupe of #478?

Thanks @DanTup. I am closing this and expecting #478 is solved with the issue being fixed.