docs: instruct Claude Code to attach CI labels when opening PRs - #436
Merged
Conversation
.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
Collaborator
Author
|
Corrected the label table: it's 🤖 Generated with Claude Code https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm Generated by Claude Code |
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
.github/workflows/check.yml'spull_requesttrigger fires only onopened,synchronizeandreopened— notlabeled. Several jobs are gated on a label being present in that triggering event's payload (host,Apple 🍎,Android 🤖,MacOS 💻,Ferric 🦀,weak-node-api). Sincecreate_pull_request(the GitHub MCP tool used to open PRs) has nolabelsparameter, 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 neededhost/Apple 🍎/Android 🤖for real coverage, but the labels were only attached after the PR was opened, so the Check run had already evaluated thoseif:conditions without them.Adds
.claude/CLAUDE.mddocumenting:synchronizeevent re-evaluates the gated jobs with labels presentThis is a base against
mainper the request that prompted it — notnext, 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--writebefore committing).🤖 Generated with Claude Code
https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm
Generated by Claude Code