decentraland / decentraland/unity-explorer

CI: fold release-PR comments into the unified CI status comment

Open
#9,936 1 comment 0 reactions 0 assignees View on GitHub
3-low enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.