We do successfully have all the wheels we'd like, I think:
https://github.com/matplotlib/matplotlib/actions/runs/7405461070/job/20149100577?pr=27563#step:4:5

I'm going to revert this back to only attempting to publish when there's an actual tag.

The remaining question is whether the nightly upload workflow will continue to work, i.e., whether the download procedure there is compatible with actions/artifacts@v4. Do you have any idea about this@matthewfeickert?

The remaining question is whether the nightly upload workflow will continue to work, i.e., whether the download procedure there is compatible with actions/artifacts@v4.

@QuLogic Sadly I think the answer is no, without refactors. On 2023-12-15@henryiii alerted the IRIS-HEP Slack to this with the following

PSA: make sure you know the consequences before you merge upload/download-artifact’s v4 updates. Upload artifact no longer merges artifacts automatically, which is a massive change and breaks pretty much all cibuildwheel or coverage workflows. Also websites with pyodide workflows. Etc.

Actually though, you may be good as@henryiii is awesome andupdatedsp-repo-review to be able to automatically check for this andhttps://learn.scientific-python.org/development/guides/repo-review/?repo=matplotlib%2Fmatplotlib&branch=main shows that GH104

GH104 Use unique names for upload-artifact ✅

is checked as working! However, things broke forpyhf and we also were checked off as passing. :/ (haven't had time to debug this yet, so might be different)

I have yet to go through and fix things for my own projects yet (I've been AFK on holiday and my only laptop died so I have only recently gotten a loaner that I can use) so once I do that (probably next week) I can open a PR formatplotlib that would migrate the actions tov4 but if you don't want to take the time to debug that now then I would suggest staying onv3 and then updating tov4 in a new PR.

Pyhf seems to have updated one but not both actions. You have to have them match.

This looks good to me. I'm not sure what this warning is referring to though, and can't find any other info on it:

@QuLogic do you is this safe to ignore before merging?

I believe that error was in testing when it was enabled to go further than it usually is for PRs.

Yes,@ksunden is correct; I was testing out thefull workflow and removed all conditionals, so it "failed" at the end because it's not possible to deploy from the fork.

@dstansby We were just talking about this on the call and I was about to also hit the green button! Feel free to join for the next 30 minutes :)

Looks like I missed an artifact name in the nightly upload, which should be fixed in#27643.