Skip to content

docs: instruct Claude Code to attach CI labels when opening PRs - #436

Merged
kraenhansen merged 2 commits into
mainfrom
claude/pr-label-ci-instructions
Aug 13, 2026
Merged

docs: instruct Claude Code to attach CI labels when opening PRs#436
kraenhansen merged 2 commits into
mainfrom
claude/pr-label-ci-instructions

Conversation

@kraenhansen

Copy link
Copy Markdown
Collaborator

Summary

.github/workflows/check.yml's pull_request trigger fires only on opened, synchronize and reopened — not labeled. Several jobs are gated on a label being present in that triggering event's payload (host, Apple 🍎, Android 🤖, MacOS 💻, Ferric 🦀, weak-node-api). Since create_pull_request (the GitHub MCP tool used to open PRs) has no labels parameter, labels can only be attached via a follow-up call after the PR already exists — which means the gated jobs silently never run against that PR unless something pushes a new commit afterward.

This surfaced concretely on #434: it touches packages/host/cpp/RuntimeNodeApi.{cpp,hpp} and needed host/Apple 🍎/Android 🤖 for real coverage, but the labels were only attached after the PR was opened, so the Check run had already evaluated those if: conditions without them.

Adds .claude/CLAUDE.md documenting:

  • why a label added after PR creation doesn't retroactively trigger gated jobs
  • a label → job → "attach when the diff touches…" table for the six label-gated jobs
  • the required follow-up: attach labels, then push one more commit (even a trivial/empty one) so a synchronize event re-evaluates the gated jobs with labels present

This is a base against main per the request that prompted it — not next, since the repo's other content conventions live there but .claude/ is tooling/agent-instruction surface rather than package code.

Testing

  • pnpm exec prettier --check .claude/CLAUDE.md — passes (also reformatted the table via --write before committing).

🤖 Generated with Claude Code

https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm


Generated by Claude Code

.github/workflows/check.yml's pull_request trigger fires only on opened,
synchronize and reopened — not labeled. Several jobs are gated on labels
being present in that triggering event's payload (host, Apple 🍎,
Android 🤖, MacOS 💻, Ferric 🦀, weak-node-api), so a label attached after
PR creation (the only way the create_pull_request MCP tool allows, since it
has no labels parameter) never actually triggers those jobs without a
follow-up push.

Adds .claude/CLAUDE.md documenting the label -> job mapping and the
attach-then-push-again workflow, prompted by PR #434 needing labels added
and retriggered after the fact.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm
kraenhansen pushed a commit that referenced this pull request Aug 13, 2026
The job checked for a label literally named "host", but the repository's
real label (used on issues, e.g. #428/#420/#412) is "Host 🏡" — a label
named plain "host" existed too, seemingly a leftover/duplicate, and has
since been deleted. The condition never actually matched the label anyone
would apply in practice, so this job only ever ran on pushes to main/next,
never on a labeled PR.

Found while attaching labels to this PR: the CI still showed green with
host-cpp-tests silently not running, exactly the kind of gap
.claude/CLAUDE.md (#436) exists to prevent.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm
The label table and example condition used plain "host", copied from
.github/workflows/check.yml's host-cpp-tests job at the time. That job's
condition was itself wrong — the repository's real label is "Host 🏡" (see
issues #428/#420/#412) — confirmed and fixed on #434's branch. Update this
doc to match, and note that a label condition needs to be checked against
the real, existing label rather than trusted at face value.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm

Copy link
Copy Markdown
Collaborator Author

Corrected the label table: it's Host 🏡, not host — the plain-host label just got deleted from the repo. That mismatch was also a real bug in .github/workflows/check.yml's host-cpp-tests condition, fixed separately on #434.


🤖 Generated with Claude Code

https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm


Generated by Claude Code

@kraenhansen
kraenhansen merged commit 9b8b8f6 into main Aug 13, 2026
9 checks passed
@kraenhansen
kraenhansen deleted the claude/pr-label-ci-instructions branch August 13, 2026 09:58
kraenhansen pushed a commit that referenced this pull request Aug 13, 2026
The job checked for a label literally named "host", but the repository's
real label (used on issues, e.g. #428/#420/#412) is "Host 🏡" — a label
named plain "host" existed too, seemingly a leftover/duplicate, and has
since been deleted. The condition never actually matched the label anyone
would apply in practice, so this job only ever ran on pushes to main/next,
never on a labeled PR.

Found while attaching labels to this PR: the CI still showed green with
host-cpp-tests silently not running, exactly the kind of gap
.claude/CLAUDE.md (#436) exists to prevent.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm
kraenhansen added a commit that referenced this pull request Aug 13, 2026
…ns (#434)

* Drop the host's shadowing implementations of runtime Node-API functions

Hermes' first-party Node-API (adopted in #372, integrated via
hermes_napi_host in #398) already implements the buffer functions,
napi_get_version and napi_get_node_version. RuntimeNodeApi.{cpp,hpp} still
defined all of these, and since the generated injector
(scripts/generate-injector.mts) resolves each NodeApiHost field by
unqualified name inside `namespace callstack::react_native_node_api`, the
host's shims won and Hermes' implementations were never reached.

Remove napi_create_buffer, napi_create_buffer_copy,
napi_create_external_buffer, napi_get_buffer_info, napi_is_buffer,
napi_get_version and napi_get_node_version from RuntimeNodeApi.{cpp,hpp},
letting unqualified lookup fall through to Hermes' own symbols. This also
fixes two bugs the shims carried:

- napi_get_buffer_info wrote its typed-array-kind output into a mutable
  global (`ArrayType`) that every subsequent napi_create_buffer /
  napi_create_external_buffer call read back, so calling it on e.g. a
  Float64Array corrupted every later buffer creation (and raced across
  runtimes).
- napi_create_buffer_copy accepted `result_data` but never wrote it.

napi_is_buffer / napi_get_buffer_info also become stricter, matching Node:
true/napi_ok only for Uint8Array, napi_invalid_arg otherwise, instead of
accepting any ArrayBuffer/TypedArray.

Keep napi_fatal_error's host-side implementation: Hermes routes it to
stderr, which is not logcat on Android, while the host's version reaches
logcat via the "NodeApiHost" logger tag. Documented why this one
intentionally keeps shadowing Hermes so a future sweep doesn't remove it
as dead weight.

RuntimeNodeApi.{cpp,hpp} keep their own translation unit rather than
folding into Logger-adjacent code: the file now holds exactly the one
shim the host deliberately keeps, and renaming would touch the injector,
CMakeLists and podspec globbing for no functional benefit.

Adds a changeset (patch) for the observable behavior change: addons now
see Hermes' real napi_get_node_version instead of napi_generic_failure,
and the stricter buffer type-checking. Closes #67.

Verified: pnpm install && pnpm run build, pnpm --filter react-native-node-api
run test (pre-existing failures only, confirmed present on unmodified
origin/next too - they stem from running as root, not this change),
eslint and prettier on touched files. Native C++ compilation was not
verified - no Android/iOS toolchain is available in this environment.

Closes #428

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm

* ci: fix host-cpp-tests label check to match the actual "Host 🏡" label

The job checked for a label literally named "host", but the repository's
real label (used on issues, e.g. #428/#420/#412) is "Host 🏡" — a label
named plain "host" existed too, seemingly a leftover/duplicate, and has
since been deleted. The condition never actually matched the label anyone
would apply in practice, so this job only ever ran on pushes to main/next,
never on a labeled PR.

Found while attaching labels to this PR: the CI still showed green with
host-cpp-tests silently not running, exactly the kind of gap
.claude/CLAUDE.md (#436) exists to prevent.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm

---------

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants