Closed broskoTT closed 1 month ago
Just FYI, as a stopgap solution for metal, we are running most/all UMD tests on the metal CI. They run for every push to main and every post-commit
https://github.com/tenstorrent/tt-metal/actions/workflows/umd-unit-tests-wrapper.yaml
Every push to tt-metal main, or umd main? In any case we should have a CI here if we plan to ship this as a separate component/endpoint to our products.
Every push to tt-metal main will run post-commit which includes umd tests. Example run from most recent main:
https://github.com/tenstorrent/tt-metal/actions/runs/10794191678/job/29937907086
But I agree, I think the CI should ultimately be in this repo.
That seems unnecessary, since not every commit on tt-metal will update the UMD commit used. Sounds like you're running same tests on the same version of umd? Also, this doesn't offer any guarantees for UMDs progress, i.e. this doesn't guarantee the current tip of the branch is functional.
Yes, I agree it's not the best solution and like you said it only guarantees umd is not broken for the version metal points to.
It was mainly implemented to have some sort of verification for UMD (since at that time we aren't able to get CI machines onto the UMD repo). Also on the off chance that metal exposes an edge-case bug in umd.
It also allowed us to dispatch umd tests on CI through this pipeline: https://github.com/tenstorrent/tt-metal/actions/workflows/umd-unit-tests-wrapper.yaml
The tests themselves run fast enough such that they don't affect the total runtime of post-commit. If development is ramping up on UMD, CI should def be present in this repo, but temporarily it's possible to validate through metal CI if needed.
Nothing to add for know, it should be pretty clear. Guard the UMD with tests