Notify Slack when the tests of the latest release fail

[albertvillanova]

This PR makes the Tests latest TRL release with dev dependencies workflow notify Slack when it fails.

Alternative to #6899, which removes the workflow instead. The two are mutually exclusive, pick one.

Motivation

The Post to Slack step of that workflow has no if:, so it inherits the default if: success() and only runs when every preceding step succeeded. It can only ever post 🟢 Tests are passing!, and status: ${{ job.status }} is always success when it is evaluated.

The consequence is that the workflow has never reported a failure. 29 of its last 100 runs failed, including six consecutive days from 2026-07-23 to 2026-07-28, without a single notification. It is the only call site missing the condition: slow-tests.yml, tests_python_versions.yml, tests.yml, tests_transformers_branch.yml and docker-build.yml all gate their Slack step on always() or on an explicit condition including it.

Which one to pick

The case for removing it (#6899) is that it spends a GPU runner nightly on a signal nobody reads, and that the failures it does produce are not the ones it exists to catch. The 2026-07-24 one is representative:

FAILED tests/test_sft_trainer.py::TestSFTTrainer::test_train_with_liger
  RuntimeError: gemm input type at::BFloat16 and output type float is only
  supported for CUDA devices with compute capability 8.0 or higher

That is the T4 of aws-g4dn-2xlarge, compute capability 7.5. The workflow is on that runner group rather than the L40S used elsewhere because it checks out an old release branch, so its results diverge from the rest of our CI.

The case for keeping it is that nothing else covers what it covers:

• tests.yml runs the same three dependencies from git in its Tests with dev dependencies job, but it has no schedule: it only runs on pushes. Breakages coming from upstream are driven by the calendar, not by our pushes.
• tests_python_versions.yml does run daily, but installs ".[dev]" only, so it gives no signal on development versions.

So this is currently the only daily signal against the development versions of accelerate, datasets and transformers, and it also covers the released branch rather than main, which matters because we ship patch releases.

There is evidence of what it catches, which @qgallouedec documented in #6899 (comment) and which is worth recording here, since #6899 will be closed and this is the PR that stays in the history of the file:

• The workflow was created in reaction to a real incident. Feature: print tokens per second during training transformers#34507 added a start_time argument to Trainer.log(), merged 2024-11-19, and broke the released TRL when it shipped in transformers 4.47.0 on 2024-12-05. A user reported it in TypeError: DPOTrainer.log() takes 2 positional arguments but 3 were given #2445 before we noticed, an emergency pin went out the same day as Pin transformers version <4.47 #2447, released as v0.12.2, and the workflow was added four days later in ⚖️ Add tests_latest.yml workflow file #2457 so that users are not our canary. It could have been caught 18 days earlier.
• 🚨 Unify 3D position ids transformers#43972 (mm_token_type_ids, merged 2026-02-24) broke us again. main was fixed two days later in Handle mm_token_type_ids in SFT/GRPO/RLOO to fix IndexError #5178, so the dev-dependencies job on main went back to green, while users on v0.29.0 hit the IndexError for real once transformers 5.3.0 shipped on 2026-03-04. For the 16 days until v0.29.1 delivered the fix on 2026-03-20, this nightly was the only CI reporting the breakage.

That second incident is the point the analysis above misses: the dev-dependencies job on main cannot catch this class of breakage by design, because main gets fixed within days and its CI returns to green while the released version stays broken. This workflow reports what users will hit when the next upstream release ships, which is also what tells us what the next patch release needs.

Changes

• Add if: always() to the Post to Slack step of tests_latest.yml, so failures are reported like in every other workflow

---

Note

Low Risk
One-line CI condition change; no application, auth, or data-handling code is modified. Only Slack notification behavior on job failure changes.

Overview
Makes the daily tests_latest.yml Slack step run even when tests fail by adding if: always().

Previously the step inherited GitHub’s default if: success(), so it never posted failures. This matches how other CI workflows already gate Slack notifications.

^{Reviewed by Cursor Bugbot for commit af2f656. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.