binary upload job is uploading all artefacts regardless if that run created them.

[nabobalis]

We have two action runs to compile wheels, one for a range of platforms and one for aarch64.

If you see https://github.com/sunpy/sunpy/actions/runs/9915099064 for an example.

The upload step for the non-aarch64 run also tries to upload the aarch64 wheel which feels like it shouldn't be doing?

Is this expected behaviour?

[ConorMacBride]

Hi @nabobalis! The upload section for both publish jobs currently downloads all build artifacts for the ci.yml workflow run matching dist-*, which is why you are seeing the wrong wheels. So it looks like we need to update publish.yml to use more unique build artifact names; ones that include the job name used within the caller workflow e.g. publish_exotic. I'm not sure how we access that name within the reusable workflow but it should be somewhere.

[aayaan758]

Hey @nabobalis, I’d like to work on this issue!

I noticed that the run link in the original description now returns a 404, but the problem itself still seems valid. From what I understand, the publish job is downloading all artifacts that match dist-* across the entire workflow run, which causes the non-aarch64 publish job to also pick up the aarch64 wheels. I can work on updating the workflow so that each build job uploads artifacts with unique names , and then update publish.yml to download only the correct artifact for that job.
Please let me know if this is still open — I’m happy to start working on it.

[nabobalis]

Hello @aayaan758, it is not up to me if you want to work on this issue.

The bug is still valid but Actions does not keep the logs for long which is why it 404s. Seeing it fixed would be great.

[aditya-pandey-dev]

Hi @nabobalis @Cadair, I’d like to work on this issue. Here is how I’m planning to approach it:

Reproduce and understand the current behaviour :
I’ll start by studying the existing workflows (ci.yml and publish.yml) to see exactly how the build and publish jobs are wired together. In particular, I want to confirm how the reusable workflow uploads wheels and how the publish jobs pick them up. The goal of this step is to fully understand why the non‑aarch64 publish job is able to see the aarch64 wheel at all.​

Locate the upload / download steps and identify the root cause :
Next, I’ll focus on the upload and download steps that handle artifacts. From the description and comments, it looks like the reusable workflow currently uses a pattern like dist-*, which means each publish job ends up downloading all wheels produced in the whole workflow run. I’ll trace which artifact names are created for each build job and how they are referenced later, so the exact failure mode is clear.​

Design a safer artifact naming and selection scheme :
Once the current flow is clear, I’ll propose a stricter mapping between build jobs and artifacts. The idea is for each build job (for example, aarch64 vs non‑aarch64) to upload its wheels under a unique artifact name that encodes the job or target platform. Then the corresponding publish job will only download the artifact that matches its own job/platform, instead of using a broad dist-* pattern.​

Implement changes in the workflow files :
I’ll implement this scheme in a feature branch by updating publish.yml and, if needed, the reusable workflow:

adjust the upload‑artifact step to use unique names per job (for example including the job name or matrix values),

update the download‑artifact step so each publish job requests only its own artifact name.
I’ll keep the changes minimal and consistent with the existing style of the workflows.​

Test with representative runs :
After that, I’ll test the updated workflows. Since the original example run now returns a 404, I’ll either create a minimal matrix‑based test workflow in a fork or reuse an existing project that uses these workflows to simulate both aarch64 and non‑aarch64 builds. I’ll verify that:

each build job uploads a distinct artifact, and

each publish job only uploads the wheels it produced, without picking up the other job’s wheels.​

Here’s my roadmap diagram for the contribution steps:

[aditya-pandey-dev]

GitHub automatically marked my previous comment as spam. This was not intentional spam it’s just my detailed plan and diagram for working on this issue. Please let me know if I should repost it in a shorter form.

[nabobalis]

As I can't see the message, I don't know what triggered it.

If you think you have a way forward, go ahead. Maybe talk to @aayaan758 as well.

[ConorMacBride]

@aditya-pandey-dev I marked the comment as spam as it is LLM generated, without any apparent additional input or independent thought from the comment author. We are happy to discuss how to implement code changes, but not if it feels like we are talking to an LLM. LLMs are a great tool for thinking through solutions and writing code, however comments, issues and PRs are unlikely to receive consideration/feedback if they appear to be mostly AI generated, or if messages are too long or unnecessarily detailed — it just adds to the workload of maintainers.

[aditya-pandey-dev]

Thanks for the feedback I did use an AI tool to help structure my thoughts but I understand that issues and PRs should be in my own words and kept short.From now on I’ll keep comments shorter and in my own words from now on and focus on actual changes or specific questions instead of long plans.

[aditya-pandey-dev]

My plan is: give each build job its own artifact name for example, include the job or arch in the name,change the publish step so it only downloads that one artifact name, instead of dist-* for the whole run,then run the workflow and check that each publish job only uploads its own wheels. This is my approach for this issue

[aayaan758]

@aditya-pandey-dev i tried the same approch but im stuck somewhere in bw, go for it if u think u can do this

[aditya-pandey-dev]

I’ve started looking into this in a fork.
I set up a small test workflow that calls the reusable publish workflow and I’m able to reproduce the issue: the non‑aarch64 publish job is still picking up all dist-* artifacts from the run, including the aarch64 wheel.
My next step is to switch to per‑job artifact names and have each publish job download only its own artifact. Before I go ahead, do you have a preference on the naming? For example would wheels-aarch64 / wheels-x86_64 be enough, or would you rather include the Python version in the name as well?

[nabobalis]

Naming of the job?

[aditya-pandey-dev]

I was thinking of using a name that includes the job/target, for example wheels-${{ matrix.target }} so that each build job gets its own artifact and the matching publish job only downloads that one. If needed we could also add the Python version for example : wheels-${{ matrix.target }}-py${{ matrix.python }} . What's your opinion.