decentraland / decentraland/unity-explorer
CI: fold release-PR comments into the unified CI status comment
- Dominant language
- C#
- Stars
- 23
- Forks
- 17
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 101
Description
## Context
The unified CI status comment work ([#9713](https://github.com/decentraland/unity-explorer/pull/9713), plus companions [explorer-automation#86](https://github.com/decentraland/explorer-automation/pull/86) for InWorld and [performance-testing#19](https://github.com/decentraland/performance-testing/pull/19) for perf) collapses the recurring CI bot comments into **one** comment on **normal PRs into `dev`**.
**Release/hotfix PRs do _not_ converge to one comment**, and this issue tracks fixing that later.
## Why it doesn't fold on a release PR
The unified `` comment is only ever *created* by a build/test workflow running on the PR head (`build.py`'s live comment during a `build-unitycloud` run, or the `pr-comment-*` workflows on a build/test `workflow_run`).
On a release PR none of those run:
- `create-release-branch.yml` opens the PR with `GITHUB_TOKEN`, whose events start no workflows.
- It **reuses dev's build** rather than triggering a new one on the release PR head.
So nothing seeds the unified comment, and the two external folders both fall back:
- **InWorld** (explorer-automation#86) writes with `NO_CREATE=1` → no unified comment found → `exit 3` → posts its standalone `## InWorld suite` comment.
- **Perf** (performance-testing#19) same, and usually isn't even dispatched on a release PR (the bare-metal dispatch fires after a *successful build run*, which doesn't happen here).
- **`create-release-branch.yml`** posts its own standalone "latest dev build" links comment (never part of the consolidation).
### Illustrating example
Release PR [#9924](https://github.com/decentraland/unity-explorer/pull/9924) (`release/2026-08-31` → `main`) shows exactly this: two bot comments, neither carrying the `` marker —
1. `create-release-branch.yml`'s `![badge]` "latest dev build" links comment;
2. the standalone `## InWorld suite` comment.
## Proposed approach
Make `create-release-branch.yml` the **seeder** of the unified comment on release PRs:
- Replace its `gh pr comment` / PATCH step with a call to `.github/actions/ci-status-comment/upsert-ci-status.sh` using `SECTION=build` and the reused-dev-build links as the body — **without** `NO_CREATE` (it runs in-repo under `github.token`, so the comment is authored by `github-actions[bot]` and later folders can find it).
- This creates the `` comment (seeding the skeleton) at branch-cut, ~40 min before InWorld finishes.
- InWorld (#86) then finds it and folds into the `inworld` section instead of falling back to a standalone comment.
Result: one unified comment on the release PR, with a **build** section (reused dev links) + **inworld** section.
## Open decision / wrinkle
lint / tests / perf never run on a release PR, so those sections would sit at their `Waiting…` / `On demand` defaults indefinitely — slightly misleading to a reader. Options:
- have the release seeder write a "ran on dev — reused" placeholder into those sections, or
- have the build section carry that note and leave the others at default, or
- suppress the non-applicable sections for release PRs.
Pick one when implementing.
## Scope / dependencies
- New work; **not** covered by #9713/#86/#19 (those only stop `create-release-branch.yml` from *clobbering* the unified comment, via the `` exclusion in its finder — already fixed in #9713).
- Depends on #9713 being merged to `dev` (so `create-release-branch.yml`'s `ref: dev` checkout has the `ci-status-comment` action + `build` section support).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Contributor guide
Research direction
Start with .github/workflows/create-release-branch.yml and the .github/actions/ci-status-comment/upsert-ci-status.sh helper, then review the unified comment changes from #9713 and the InWorld integration in explorer-automation#86. Verify the release workflow seeds one ci-status comment that later InWorld updates, and resolve how non-applicable release checks should be represented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, shell, yaml
- Domain
- build-system, ci-cd, devops
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100