[bug] (v4) Unable to upload to same artifact name from multiple jobs

[DanTup]

What happened?

The PR from dependabot to upgrade to v4 is failing on my project with this error:

Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

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

[DanTup]

Actually, it seems this is called out here:

https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new:~:text=The%20contents%20of%20an%20Artifact%20are%20uploaded%20together%20into%20an%20immutable%20archive.%20They%20cannot%20be%20altered%20by%20subsequent%20jobs.%20Both%20of%20these%20factors%20help%20reduce%20the%20possibility%20of%20accidentally%20corrupting%20Artifact%20files.

The contents of an Artifact are uploaded together into an immutable archive. They cannot be altered by subsequent jobs. Both of these factors help reduce the possibility of accidentally corrupting Artifact files.

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.

[RobertoPrevato]

Well, this is a bad news for me. I find convenient to use the upload-artifact to write different files to the same folder in a build matrix. For example to compile custom C extensions for several combinations of Python versions and operating systems, and publishing to a single folder.

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 v3 and I hope this will be reconsidered in a future version of these actions.

[DanTup]

Yeah, I rolled back to v3 too. Until I'm forced to upgrade, the old way is much more convenient for me.

[seanvaleo]

I had to roll back also

[ptr727]

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 :(

[DanTup]

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).

[jennydaman]

It was just announced that v3 will be disabled on 2024-11-30.

https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/

It is disappointing that the disabling of v3 was announced before v4 reaching feature-completeness.

[sameeraksc]

We are having the same issue

[stweil]

Then update your code. The description how to do that can be found above.

[liyishuai]

Take a look at main/docs/MIGRATION.md#overwriting-an-artifact

      - name: New override option
        uses: actions/upload-artifact@v4
        with:
          name: build-artifact
          path: ./example
          overwrite: true

Thanks for the notice! Seems like #501 has fixed the issue here.

[stweil]

If your old configuration merged the artifacts, then overwrite: true would be the wrong choice. Use merge-multiple: true.

[charlieforward9]

I worked around this problem by appending ${{ github.run_number }}-${{ github.run_attempt }} to the artifact name. This guarantees a clean, traceable, unique name on every (re)run.

[dreinhardt89]

I'm setting overwrite: true and still getting this am I missing something?

Run actions/upload-artifact@v4
  with:
    name: tf-module-cache-key-file
    retention-days: 3
    path: .terraform/modules/modules.json
    overwrite: true
    if-no-files-found: warn
    compression-level: 6
  
With the provided path, there will be 1 file uploaded
Artifact name is valid!
Root directory input is valid!
Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

[jsoref]

@dreinhardt89: you shouldn't use overwrite: true, you should give each of your artifacts a distinct name and then use the merge subaction: https://github.com/actions/upload-artifact/blob/main/merge/README.md

[josephleung5]

this migration guide should help?
https://github.com/actions/download-artifact/blob/main/docs/MIGRATION.md