[skip ci] Add support for both 20.04 and 22.04 in package and release workflow

[ayerofieiev-tt]

Ticket

None

Problem description

Need both 20.04 and 22.04 wheels for Pytorch backend

What's changed

Uploads
ttnn-0.0.dev1+any-cp310-cp310-linux_x86_64.whl

ttnn-0.0.dev1+any-cp38-cp38-linux_x86_64.whl

See how version is wrong - 0.0.dev1

Checklist

• Package and release
• All Post-Commit

[ttmchiou]

it looks like these changes also disables all the model perf and device perf tests here?
is this intentional?

[ayerofieiev-tt]

@ttmchiou can you clarify why do you think so? I expect they keep running, but instead of running on both 22.04 and 20.04, they only run on 20.04 as before.

[ttmchiou]

https://github.com/tenstorrent/tt-metal/actions/runs/13213125243

It looks like in this run that all the demo/perf pipelines all are in a pending state. Clicking into a run says the job is skipped?
Related to the if condition change for pipelines i would assume to maintain that they continue running for 20.04.

[blozano-tt]

https://github.com/tenstorrent/tt-metal/actions/runs/13213125243

It looks like in this run that all the demo/perf pipelines all are in a pending state. Clicking into a run says the job is skipped? Related to the if condition change for pipelines i would assume to maintain that they continue running for 20.04.

@ttmchiou good catch.

@ayerofieiev-tt
I think there is something wrong with this logic:

if: ${{ contains(needs.build-artifact.*.outputs.version, '20.04') }}

version is not an output of build-artifact.

[ayerofieiev-tt]

You are right. Thanks!

Any advice on how this can be fixed?

[ttmchiou]

did you try the recommendations I commented on?

[ayerofieiev-tt]

@ttmchiou if you refer to this comment #17755 (comment) I am not sure how to specify those jobs to only run on 20.04
I assume maybe I can simply remove the condition.

[ayerofieiev-tt]

@ttmchiou , @blozano-tt , fixed.

But we need to fix the naming asap. This "dev13" thing is painful. I was not able to find where its coming from, but it is not coming from this PR, it is the current state of main basically.

ttnn-0.56.0rc24.dev13+any-cp310-cp310-linux_x86_64.whl

ttnn-0.56.0rc24.dev13+any-cp38-cp38-linux_x86_64.whl

[blozano-tt]

@ttmchiou , @blozano-tt , fixed.

But we need to fix the naming asap. This "dev13" thing is painful. I was not able to find where its coming from, but it is not coming from this PR, it is the current state of main basically.

ttnn-0.56.0rc24.dev13+any-cp310-cp310-linux_x86_64.whl

ttnn-0.56.0rc24.dev13+any-cp38-cp38-linux_x86_64.whl

We fixed all of our issues on main. Thanks to @dimitri-tenstorrent.
I merged main into this PR, and resolved the merge conflicts.

[blozano-tt]

I need to block this until we can confirm that it doesn't break all-post-commit and all the workflows that depend on build-artifact.

I think the change to the build-artifact artifact upload will break downstream workflows that download the artifact.

Yeah: This breaks CI

@afuller-TT you highlighted a while back that we need to fix artifact naming to support having multiple artifacts at play in a single workflow...

I am thinking build-artifact workflow should output an "artifact-name" string, for downstream workflows. Just like you were planning for docker-image.