fix(ci): enable include-component-in-tag to fix auto-tagging#196
Merged
Conversation
…o-tagging
release-please v4's buildRelease checks:
normalizeComponent(branchName.component) !== normalizeComponent(branchComponent)
and returns early (skips release creation) on mismatch.
branchName.component comes from parsing the merged PR's title.
branchComponent comes from getBranchComponent() which falls through
to getDefaultPackageName() → root package.json name ("lobu-monorepo")
when component/package-name is empty or unset (JS || treats "" as falsy).
Fix: set package-name to "lobu" (controls the expected component) and
include ${component} in the title pattern so the parser can extract it.
Result: titles like "chore(main): release lobu 3.4.4", and the
component check passes ("lobu" === "lobu").
include-component-in-tag remains false, so tags stay as v3.4.4 (no
component suffix).
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This was referenced Apr 16, 2026
Closed
Closed
Closed
buremba
added a commit
that referenced
this pull request
May 19, 2026
Two-part fix discovered while shipping owletto#196: 1. The "E2E before merge" exception said agents can't reach Mac/Xcode dev environments. xcodebuild actually runs headlessly from Bash (verified: `xcodebuild -project Owletto.xcodeproj -scheme Owletto -configuration Debug -destination "platform=macOS" build CODE_SIGNING_ALLOWED=NO` produced "BUILD SUCCEEDED" on every commit of #196 without any human in the loop). Compile-checks aren't exempt; only UI/runtime validation is. Reworded the exception and added the xcodebuild command to the validation table so agents pick the right tool by package. 2. "Cross-repo dispatch" said owletto changes go through a standalone clone at ~/Code/owletto. That clone was retired this session in favour of `make task-setup NAME=<slug>` worktrees which set up packages/owletto on a real named branch under the worktree — matching how owletto#196 was actually shipped.
buremba
added a commit
that referenced
this pull request
May 19, 2026
* chore: bump owletto submodule pointer to lobu-ai/owletto#196 Picks up: - feat(mac): Cancel button for the OAuth sign-in flow (#196) Before: 4f7c757 feat: per-agent guardrail toggle + recent trips view After: 05e966b feat(mac): Cancel button for the OAuth sign-in flow * docs(agents): correct the Mac/Xcode validation exception Two-part fix discovered while shipping owletto#196: 1. The "E2E before merge" exception said agents can't reach Mac/Xcode dev environments. xcodebuild actually runs headlessly from Bash (verified: `xcodebuild -project Owletto.xcodeproj -scheme Owletto -configuration Debug -destination "platform=macOS" build CODE_SIGNING_ALLOWED=NO` produced "BUILD SUCCEEDED" on every commit of #196 without any human in the loop). Compile-checks aren't exempt; only UI/runtime validation is. Reworded the exception and added the xcodebuild command to the validation table so agents pick the right tool by package. 2. "Cross-repo dispatch" said owletto changes go through a standalone clone at ~/Code/owletto. That clone was retired this session in favour of `make task-setup NAME=<slug>` worktrees which set up packages/owletto on a real named branch under the worktree — matching how owletto#196 was actually shipped.
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
1 participant
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
The actual root cause: release-please's
getComponent()returns""wheninclude-component-in-tag: false, so component never appears in PR titles. ButgetBranchComponent()ignores that flag and returns the real component from package.json. ThebuildRelease()check compares these two values andreturn;s on mismatch — silently skipping release creation.Fix: Set
include-component-in-tag: true+package-name: "lobu". This makes bothgetComponent()andgetBranchComponent()return"lobu", the title includes it, and the check passes.Tag format changes:
v3.4.4→lobu-v3.4.4. All downstream workflows (publish, Docker) use the tag_name output, not a hardcoded format.Title format:
chore(main): release lobu 3.4.4Test plan