feat(triage): merge enterprise results into release triage - #883
Draft
estefafdez wants to merge 13 commits into
Draft
estefafdez wants to merge 13 commits into
estefafdez wants to merge 13 commits into
Conversation
…ngside standard suite
Merge reset_state/close_only into a single mode choice, auto-delete the old Taiga story on reset instead of requiring a manual step, and fail fast with a clear message if release_tag looks like a full build string instead of a short release name.
…3 reports The GITHUB_TOKEN-scoped gh run list lookup was seen returning a completed scheduled run 3 weeks stale (its S3 report had already expired), crashing the download step with a raw 404. Walk the last 15 candidates and use the first one whose results.json actually exists in S3, instead of trusting the very first match blindly.
Temporary, removed right after use once #2569/#2570 are deleted.
GitHub only recognizes workflow_dispatch workflows once they've existed on the default branch — a brand-new workflow file on a feature branch can't be dispatched via API/CLI (404), so this approach doesn't work.
Discovered while testing: a story already exists in production tagged with a full build string. The hard-fail check would have made it impossible to keep adding to that exact story, so this only warns in the job summary now — intentionally reusing an existing tag to continue its story is a valid case, not just a mistake.
estefafdez
marked this pull request as ready for review
September 25, 2026 07:38
tdelatorre
requested changes
Sep 25, 2026
| --event schedule \ | ||
| --status completed \ | ||
| --limit 1 \ | ||
| --limit 15 \ |
Collaborator
There was a problem hiding this comment.
Why do you change this limit?
Collaborator
Author
There was a problem hiding this comment.
@tdelatorre I changed --limit 1 to --limit 15 because, when I was running and testing this workflow, gh run list returned a run from more than 3 weeks ago whose report no longer existed in S3 (it had been deleted by our bucket's retention policy). That's why, with a limit of 15 runs (~3 weeks of daily runs), we avoid picking a run whose S3 report might already be expired.
Collaborator
There was a problem hiding this comment.
@estefafdez It shouldn't grab a run from more than 3 weeks ago; there are runs every day. It should always grab the latest nitrate run and other tests run, with their reports in S3.
We should investigate why it's doing that.
estefafdez
marked this pull request as draft
September 25, 2026 10:20
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Done Definition Checks
Taiga URL (optional)
Taiga Ticket: 2523
Description
This PR resolves the release triage not covering the Enterprise suite and cleans up several confusing/rough edges in the
release-triage.ymlworkflow found while testing it end to end.What problem are you trying to solve?
The daily workflow (
playwright_pre_daily.yml) now runs both a standard (chrome) and anenterprisejob, each uploading its own report to S3.Solution
scripts/triage.ts:--resultsis now repeatable, so the standard and enterpriseresults.jsonget merged into a single clustering pass and land in the same release story instead of needing two separate triage runs (which would have stepped on each other's resolved/auto-close state). Tasks made up entirely of enterprise specs get an[enterprise]prefix in their subject.release-triage.yml: also fetches the enterprise suite's report when the run has one (falls back cleanly to standard-only otherwise).github/workflows/README.mdupdated to match.How to test
Screenshots 📸 (optional)