Note about `actions/upload-artifact@v4` about cibuildwheel

[Czaki]

It will be a big pain. In many projects, logs are combined into a single target to simplify download.

[henryiii]

Something like this, perhaps?

    - uses: actions/download-artifact@v4
      with:
        path: all

    - name: Merge files
      run: |
        mkdir dist
        mv all/*/* .
        rmdir all/*
        rmdir all

Any way to make that cleaner? (also not sure if shell: bash is required)

[alugowski]

If pypi-publish action supported recursively searching dist/ then the only change needed would be to name the uploaded artifacts. I opened an issue there: pypa/gh-action-pypi-publish#199

As of today, all that is needed is to name uploaded artifacts:

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

Update: download-artifact v4.1 now offers a merge-multiple switch:

      - uses: actions/download-artifact@v4
        with:
          path: dist
          merge-multiple: true

[henryiii]

Ouch, that affects a lot of things. The ability to simply aggregate was very useful. Is there a nice way to recombine artifacts? If you get all artifacts, you might get things you don't need, and they go into directories. I think the aggregation job will now require at least an extra step.

I'm surprised a very useful feature was axed but no clear replacement was worked out first.

[henryiii]

cibuildwheel artifacts are not in dist. They are in wheelhouse. So I’m quite sure the directory is already not included by the upload action using the expression we already have.

[webknjaz]

cc @woodruffw — this will affect the secretless publishing recommendations in the PyPI docs, PyPUG and pypi-publish README... FYI

[woodruffw]

Yeah, this seems like it'll cause quite a bit of pain for common Python publishing workflows (and maybe other ecosystems as well, like Ruby?)

Has anybody raised this upstream? The actions maintainers have been responsive to unanticipated breakages IME. Apologies if someone already has and I missed it 🙂

Edit: Sorry, I see now that an upstream issue has been raised!

[LecrisUT]

+1 for a big warning banner for the top-level Readme. At the very least if my reading is correct GH Action will raise an error instead of overwriting the old one, so people would probably turn up over here if they are silently effected.

[henryiii]

I've successfully shipped cmake with v4 and the changes above:

https://github.com/scikit-build/cmake-python-distributions/pull/438/files

[LecrisUT]

Seems like we will have a wrapper for this soon:
https://github.com/re-actors/download-artifact

[henryiii]

Compatibility score is easy, most deploy-style workflows don't break until you deploy, so the initial PR passes, but on release it breaks, since you aren't downloading the uploaded artifacts in PR jobs. Only the rarer cases, like building GitHub Pages with several input, are showing up as broken right away. In fact, I bet the 6% failure might be due to the v3/v4 compatibility instead, with only 6% downloading artifacts in a PR job.

Building up a zip file of merged outputs always seemed a little magical, so it's understandable why a complete rewrite wouldn't want to add this feature and would be much faster without it. Just think about what happens to these conglomerate zips when the order changes or when a job fails and you have to rerun it! It's sad that a lot of workflows have to change, but I think it's reasonable and am happy to have the advertised improvements. The fact you only have to add a little bit (name, merge-multiple, and pattern) and get the same feature (minus easy downloading from the UI) without any of the magic is great.

You can enter your repo at https://learn.scientific-python.org/development/guides/repo-review/ and sp-repo-review will detect workflows that are likely to be incompatible with v4 and suggested the name/merge-multiple/path solution.

[henryiii]

Exact same thing. The PR passes because it doesn’t actually use download-artifact in the PR step, only in deployment. I’ve seen a ton of these pass because of this. I’d say about 8% using download artifact in the PR step is about right.

Dependabot is not smart enough to detect if an action is actually run.

[joerick]

We've updated our docs regarding this in #1705, so I think we're all done here. Thanks everyone for chipping in!

[LecrisUT]

Agreed, I did not find a clean way other than sticking to v3 or downloading all and using the artifact name to merge it back.

I didn't check the git blame to see the discussion on when this was removed, but there was this old issue I stumbled upon: actions/upload-artifact#24

[henryiii]

If there was just something like "combine: true" (and ideally a way to list artifacts, like in actions/download-artifact#202, possibly even with globs!), then this would be much easier, and the promise of faster downloads is nice. But currently it seems really ugly to workaround for projects like cibuildwheel users (and logging, etc).

[LecrisUT]

Download wise, there is an approach by not specifying the name in download-artifact ¹, which will extract them in their corresponding name directory. It is not ideal because it will download all artifacts instead of allowing for a glob pattern.

Footnotes

1. https://github.com/actions/download-artifact/tree/v4#download-all-artifacts ↩

[LecrisUT]

Considering that this will most likely be done in a standalone job, that should be ok as being runs-on: ubuntu-latest. But I think some sanity paths are in order:

    - uses: actions/download-artifact@v4
      with:
        path: all
    - name: Merge files
      run: |
        mkdir dist
        mv all/*/dist/* ./dist

The download-artifact creates an extra directory between all and dist

[henryiii]

that should be ok as being runs-on: ubuntu-latest

🤦

The download-artifact creates an extra directory between all and dist

It shouldn't create a dist at all. The structure should be all/<name>/thing.tar.gz, etc. There is no "dist" (or "wheelhouse", for cibuildwheel) in the archives.

So this should be fine, I think:

    - uses: actions/download-artifact@v4
      with:
        path: all

    - name: Merge files
      run: |
        mkdir dist
        mv all/*/* .

(all still untested)

[LecrisUT]

It shouldn't create a dist at all.

This would depend on how you uploaded the artifact dist/* vs dist. The downloaded artifacts are automatically extracted in those folders. Granted I've only tested the later statement, but the former one has been like that since the beginning, hasn't it?

[LecrisUT]

Oh, yes indeed:

      - name: Build wheels
        run: pipx run cibuildwheel==2.16.2
      - uses: actions/upload-artifact@v3
        with:
          path: ./wheelhouse/*.whl

I was remembering these snippets in the documentation:

    - name: Build SDist
      run: pipx run build --sdist
    - uses: actions/upload-artifact@v3
      with:
        path: dist/*.tar.gz
...
    - uses: actions/download-artifact@v3
      with:
        name: artifact
        path: dist
    - uses: pypa/gh-action-pypi-publish@release/v1

[webknjaz]

Just remembered an old unfixed race condition that might've been the inspiration to break things further... actions/toolkit#1235 / actions/download-artifact#140 (comment)

[webknjaz]

@henryiii @joerick perhaps the docs should show a big scary red banner warning people not to upgrade the affected action?

[webknjaz]

Seems like we will have a wrapper for this soon:
https://github.com/re-actors/download-artifact

I'll likely archive it, after all, since the upstream implemented the new pattern: input + merge-multiple: true. It'll require some manual changes, though. Same with the upload — but this one might benefit from a wrapper. Though, maintaining wrappers would be a pain so I'll see if it'll be worth it.

[gnikit]

@alugowski This is pretty much the solution I arrived too, but because I feel uneasy with leaving the name field blank, I ended up using pattern in the download action, which is marginally better.

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

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

---

Personally, I still don't understand the reasoning behind the complete removal of this core feature in the upload action. Also, I am having a hard time believing the compatibility score from dependabot , 6% failure seems oddly low.

[alugowski]

Also, I am having a hard time believing the compatibility score from dependabot , 6% failure seems oddly low.

Nevermind the 6% upload-artifact upgrade failure rate, the surprising thing is the tiny 8% failure rate for download-artifact (before GitHub merged the two upgrades into an upgrade group). v3 and v4 actions are explicitly incompatible with each other, so the v4 download is not able to download anything uploaded by upload-artifact v3. So all workflows that use artifacts to move data between steps should fail. That suggests that 92% of workflows either don't use artifacts that way or they tolerate absolute failure in some way. Maybe they succeed with empty/missing artifacts (like deploying nothing counts as success), or maybe they use artifacts for other purposes.