Uploading to the same named Artifact multiple times -> Why the breaking change?

[turing85]

Hi!
I have multiple repositories (mostly multi-module maven projects) that use this feature heavily (to accumulate, for example, JaCoCo test reports, here (github.com) is an example of such a pipeline).

The accumulation is especially helpful for aggregated jaCoCo coverage reports. JaCoCo allows the aggregation of all submodule-reports in an overall report, but this requires all jaCoCo coverage reports. Aggregating through a multi-upload has the nice benefit that a new, parallel module build can be created through a template, and no further configuration on the downloading side is necessary.

The breaking change came as a surprise to me. I have a four questions:

1. Why exactly was this breaking change introduced?
2. Is there a chance to get this feature back in the future?
3. Is there a canonical workaround/upgrade path?
4. Is Version 3 officially EOL and will thus no longer be patched?

[gnikit]

I second that! We make heavy use this feature to compile and package C, C++ and Fortran software into Python wheels across multiple OSs and then upload them to registries. Removing this feature in v4 completely breaks these workflows. What is the recommended way now of agglomerating artefacts under a single name?

[gnikit]

The workaround I have arrived is explicitly naming the upload artefacts

      - uses: actions/upload-artifact@v4
        with:
          name: python-wheels-${{ matrix.os }}
          path: |
            ./wheelhouse/*.whl
            ./wheelhouse/*.tar.gz

and then merging them all together during retrieval

      - uses: actions/download-artifact@v4
        with:
          pattern: python-wheels*
          path: dist
          merge-multiple: true