Add iBazel protocol forwarding - #99
Open
longlho wants to merge 4 commits into
Open
Conversation
## Why Long-lived `multirun` targets often combine protocol-aware dev servers with processes that must restart after a successful rebuild. Filesystem-path routing makes each consumer reconstruct Bazel ownership, while restarting every process discards useful state. Structured iBazel events can now report affected direct-target labels. `multirun` should use that information without coupling restart policy to a particular workspace. ## What changed - add opt-in `ibazel_restart_affected_commands` behavior - record each command's Bazel label in runner instructions - restart only matching non-notification commands after successful structured events - restart all non-notification commands when ownership attribution is incomplete - preserve notification forwarding for protocol-aware commands - manage restart and shutdown process groups across Unix and Windows - document the generic workflow and add end-to-end restart coverage The initial build does not restart children. Failed builds never restart them.
## Why iBazel notification mode starts the watched target before watch discovery, then performs a catch-up build. Notification-capable dev servers can absorb that build, but user-visible commands may open before the resulting reload and visibly flash or reset. ## What changed - Add opt-in `ibazel_defer_non_notification_commands`. - Start notification-capable commands immediately. - Start remaining commands after the first successful structured build event. - Keep deferred commands stopped when the bootstrap build fails. - Preserve current immediate-start behavior by default. This is generic orchestration behavior: no knowledge of desktop apps, browsers, or any consuming repository.
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.
Why
Wrapping protocol-aware dev servers in multirun currently consumes iBazel's stdin protocol at the parent, so children such as
js_run_devservermiss rebuild notifications and HMR degrades.What changed
multirun(..., ibazel_notify_changes = True), which advertises legacy and v1 iBazel notification capabilities and runs children in parallel.commandwrappers.IBAZEL_EVENTmessages only to v1 children.Depends on ibazel@v0.30.0+ for structured
IBAZEL_EVENTnotifications. Legacy notifications continue to work with existing iBazel releases.Related: bazelbuild/bazel-watcher#833
Verification
Ran patched iBazel against the fixture and confirmed notifications arrive before stdin closes. Legacy events reach both legacy and v1 children, structured events reach only v1 children, and the plain child receives neither.