Cx Organization

[JuanPedroGHM]

Due Diligence

• General:
  • title of the PR is suitable to appear in the Release Notes
• Implementation:
  • unit tests: all split configurations tested
  • unit tests: multiple dtypes tested
  • NEW unit tests: MPS tested (1 MPI process, 1 GPU)
  • benchmarks: created for new functionality
  • benchmarks: performance improved or maintained
  • documentation updated where needed

Description

Goal is to organize our workflows by modularizing certain steps and jobs.
Reusable workflows should be turned into actions, that can be added onto larger workflows.

Anger towards #1937 made me finish this out of spite. It does all the changes proposed. Let's talk about what's missing.

Benchmarks are also working again.

What are we getting from this

• More detailed test reports in gitlab and codecov (allegedly)
• Actions that are easier to maintain and workflows that are easier to plan.

TODO

• Clean-up secrets and old tokens
• Change GH_TOKEN, CB cannot comment on pr's at the moment.
• Restore full CI runs (after pr approved, and on main?)
• Somehow test the weekly workflow.
• Make sure special cases CI cases (support) are somehow handled properly.

See #1874 Cx section for rationale.

Changes proposed:

• Weekly actions packed into weekly workflow
• A single Github CI Action
• A single Codebase CI Action
• A single Benchmark trigger action
• A PR open/update workflow
• A PR approve workflow
• A push to main workflow
• NO MORE THANKING YOU FOR THE PR!

[github-actions]

This pull request is stale because it has been open for 60 days with no activity.

[brownbaerchen]

What is the status of this PR? Is this still relevant after #2139? Some things like removing thanking for PR are certainly still relevant but may be better merged separately.

[JuanPedroGHM]

Updates based on the review comments:

• On Push PR also triggers when opening/reopening a PR, to get instant tests.
• On Push PR, the github tests are closer to the medium tests, testing the oldest and newest python and pytorch versions, without any dependencies. It makes sense to do this, we would rather not find the compatibility issues after a merge to main.
• Tests will still not run dependabot PR's, I don't think it makes sense 99% of the time, but they can be triggered manually by creating a "fake" commit if we feel the need to test it.

[mtar]

Some action SHA pinning for security. It's non-critical code though.

[JuanPedroGHM]

@brownbaerchen From your last comment: changes to github workflows will be tested on PR Open/Update (unless they have dependabot/** branch), to ensure that they work (just like the ones here), but I would say, once they work on the PR, there is no need to test them on main. Many dependabot merges won't clog the CI anymore. Same principle applies to documentation changes, or other non-source code changes.

[JuanPedroGHM]

Benchmarks results - Sponsored by perun

FTPx86-AMD-Milan-Mi250 - CPU - N4 - RUNTIME

Function	Value [s]	Change %	30 day avg. [s]	Last entrie [s]

---

FTPx86-AMD-Milan-Mi250 - GPU - N4 - RUNTIME

Function	Value [s]	Change %	30 day avg. [s]	Last entrie [s]

---

Grafana Dashboard
Last updated: 2026-05-20T13:37:26Z

[JuanPedroGHM]

Pipeline running after downgrading ROCM to 6.4, also changed github actions to use mpich, for the tests.

[brownbaerchen]

I added a few skip statements to jobs that should be skipped on forks. Otherwise, this looks really good. Once push to main doesn't trigger codebase CI on forks, it's ready to be merged in my opinion.

[brownbaerchen]

Thanks, @JuanPedroGHM! This is really a substantial improvement!