[amondnet]

Summary

Every CI run on a release-please PR has been parked at action_required and never executed — including the one that shipped v0.1.0.

$ gh run list --branch release-please--branches--main --workflow ci.yml
CI [pull_request] completed/action_required c44ee37   <- the current 0.1.1 release PR (#15)
CI [pull_request] completed/action_required 11b8e8b
CI [pull_request] completed/action_required 77eedc2
CI [pull_request] completed/action_required cefb345   <- shipped as v0.1.0

Cause. The org requires workflow approval for first-time contributors, and github-actions[bot] never becomes one:

$ gh api repos/pleaseai/openhwp/actions/permissions/fork-pr-contributor-approval
{"approval_policy":"first_time_contributors"}

release-please ran on the default GITHUB_TOKEN, so it authored its PRs as that bot and their workflow runs stayed pending approval. Dependabot is unaffected (#3/#4/#5 all show CI completed/success) because it has its own trusted lane.

Why this is worse than it sounds. The failure is quiet. GitHub Apps — CodeQL, SonarCloud, Socket — are not subject to the gate and report normally, so a release PR presents a wall of green checks while check and smoke never ran. v0.1.0 merged in exactly that state.

Fix

Switch release-please to a pleaseai-release-bot app token, matching pleaseai/shunt and pleaseai/code-intelligence. Shunt's workflow comment states the same rationale, so this brings openhwp in line rather than inventing a pattern.

No admin action is required — everything already exists:

Prerequisite	Status
pleaseai-release-bot app (id 2162598)	installed org-wide, repository_selection: all
vars.RELEASE_GITHUB_APP_CLIENT_ID	org variable, resolves for this repo
secrets.RELEASE_GITHUB_APP_PRIVATE_KEY	org secret, resolves for this repo

Job-level GITHUB_TOKEN permissions are dropped, since every write now goes through the app token (least privilege, and what shunt does).

This also fixes a second latent problem: a tag pushed with GITHUB_TOKEN does not trigger downstream workflows, so any future release/publish workflow keyed on the tag would silently never fire.

Verification

• actions/create-github-app-token@bcd2ba4 verified against upstream — gh api repos/actions/create-github-app-token/git/ref/tags/v3.2.0 returns exactly that SHA, so the pin is genuinely v3.2.0 and not a copied value.
• Both actions are pinned to full 40-char SHAs per the OSS policy.
• Workflow YAML parses; deno task check, deno lint, deno fmt --check pass.
• Note the proof is necessarily post-merge: this workflow only runs on push to main.

Follow-up on the open release PR

#15 was authored by github-actions[bot] before this change, so its CI is still gated. Once this merges, release-please re-runs as the app and updates that branch, which should let CI run. If it doesn't, closing #15 and letting release-please recreate it clears the stale author.

Separately, I verified #15 by hand in the meantime (deno task check / lint / fmt --check against c44ee37, all pass) — which also confirms the #10 fix works: it bumps apps/desktop/deno.json 0.1.0 → 0.1.1 and leaves the root deno.json untouched.

Related issue

Closes #11

Checklist

• PR title follows Conventional Commits
• Tests added or updated — n/a, CI configuration (the repo has no deno test suite yet)
• Lint/format pass (deno lint / deno fmt --check)
• Documentation updated if behavior changed — rationale documented in the workflow header
• No breaking change

---

Summary by cubic

Run release-please with the pleaseai-release-bot app token so release PRs get CI. Fixes stuck action_required runs from github-actions[bot] and lets tag pushes trigger downstream workflows.

• Bug Fixes
  • Use actions/create-github-app-token to mint an app token from vars.RELEASE_GITHUB_APP_CLIENT_ID and secrets.RELEASE_GITHUB_APP_PRIVATE_KEY.
  • Pass the token to googleapis/release-please-action; remove job-level GITHUB_TOKEN write permissions.
  • Matches the pattern used in pleaseai/shunt and pleaseai/code-intelligence.

^{Written for commit 62c2354. Summary will update on new commits.}

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[greptile-apps]

Greptile Summary

This PR updates release automation to use a short-lived GitHub App token.

• Mints the token from organization-level client ID and private-key configuration.
• Passes the token to release-please so release PRs and tags can trigger downstream workflows.
• Removes the now-unnecessary write permissions from the default GITHUB_TOKEN.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The token action inputs and output wiring are consistent, the workflow remains limited to pushes on main, and the default GitHub token no longer retains unnecessary write permissions.

Important Files Changed

Filename	Overview
.github/workflows/release-please.yml	Correctly replaces the default workflow token with a SHA-pinned GitHub App token and passes it to the SHA-pinned release-please action.

_{Reviews (1): Last reviewed commit: "ci: run release-please with an app token..." | Re-trigger Greptile}