ci(release): use linearis-bot app token and list included PRs

[iamfj]

What does this PR do?

Updates promotion workflow to authenticate with the linearis-bot GitHub App instead of GITHUB_TOKEN, and changes promotion PR body content from included commits to included pull requests with author attribution and thanks.

Type of change

• Build / CI
• Refactor (no behavior change)
• Bug fix
• New feature
• Documentation
• Tests

Checklist

• npm run check:ci passes (lint + format)
• npx tsc --noEmit passes (type check)
• npm test passes (unit tests)
• New code has tests (happy path + primary error case)
• Commit messages follow Conventional Commits

Testing

Ran in worktree:

• npm run check:ci (Biome schema-version info exists in repo: config 2.4.11 vs CLI 2.4.10)
• npx tsc --noEmit (fails in baseline because generated src/gql/graphql.js not present in worktree)
• npm test (fails in baseline for same missing generated file)

Workflow logic reviewed by inspection:

• App token generated via actions/create-github-app-token@v2 using RELEASE_APP_ID + RELEASE_APP_PRIVATE_KEY.
• gh pr list/edit/create now use app token.
• Included PR list built from origin/main..origin/next commits via GraphQL associatedPullRequests, deduped by PR number.

Notes for reviewers

• Target branch is next because promotion workflow is driven by next pushes.
• If a commit has no associated PR mapping, workflow skips it and continues.
• If no PRs are found, workflow uses fallback line.

[chatgpt-codex-connector]

💡 Codex Review

linearis/.releaserc.cjs

Line 18 in 1a5949b

{ publishCmd: "npx clean-publish --access public -- --provenance" },

Publish next-channel releases with a prerelease dist-tag

The semantic-release publish command uses npx clean-publish --access public -- --provenance without a --tag, so npm falls back to its default dist-tag (latest). With next configured as a prerelease branch, versions like 2026.4.8-next.1 would be published to latest, causing normal npm install linearis consumers to receive prerelease builds unexpectedly. This should set a branch-aware tag (for example next on the prerelease branch) or delegate publish to @semantic-release/npm.

---

linearis/.github/workflows/ci.yml

Line 167 in 1a5949b

output=$(git log "$base_ref"...HEAD --name-status --pretty=format: -- CHANGELOG.md | sed '/^$/d')

Limit CHANGELOG guard to commits on the PR branch

This guard uses a symmetric range ($base_ref...HEAD), which includes commits that exist only on the base branch. In ci.yml, that means a main release commit touching CHANGELOG.md can make unrelated feature PRs fail even when the PR branch never changed CHANGELOG.md; the check is then enforcing branch freshness instead of “PR touched changelog.” Use a head-only range ($base_ref..HEAD) to detect only changes introduced by the PR branch.

---

linearis/.github/workflows/release-check.yml

Line 110 in 1a5949b

GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Create releases with a token that can trigger workflows

The release job runs semantic-release with ${{ secrets.GITHUB_TOKEN }}, but release events created with GITHUB_TOKEN do not trigger downstream workflows. Since this commit adds release-triggered automation (promote-next-to-main.yml and sync-main-release-back-to-next.yml) and release commits are marked [skip ci], those follow-up workflows can be skipped after successful releases. Use an app/PAT token for the GitHub release step so release events can fan out to those workflows.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[iamfj]

Addressed feedback in latest push:

• Switched prerelease publish dist-tag behavior: .releaserc.cjs now sets --tag next on next branch and --tag latest on main.
• Updated CI history guards to use head-only ranges (base..HEAD) so checks only inspect commits introduced by PR branch:
  • guard-changelog-history
  • guard-plan-files
• release-check already uses GitHub App token (GH_TOKEN/GITHUB_TOKEN) on current next, so downstream release-triggered workflows can fire.

If preferred, I can split the non-promotion fixes into a separate PR.