RemoteSpawnRunner: record inbetween phases in timing profile #20387
Conversation
This file contains 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
github-actions
bot
added
team-Remote-Exec
|
cc: @tjgq 🙏 |
|
would be nice if we could target this for 7.1 and 6.5 (if there is a 6.5) |
tjgq
reviewed
Dec 7, 2023
src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnRunner.java
Outdated
Show resolved
Hide resolved
After an action was executed remotely, RemoteSpawnRunner would use the timestamps in the execution metadata to record appropriate timing phases into the JSON profile. However, there are durations in-between the existing phases that are unaccounted for. Depending on the RBE server implemenation, these phases could mean different things: - Sandbox preparation - Cleaning up sandbox environments post-execution - Others Missing these durations inside the timing profile would cause confusion to end users as it would be interpreted as nothing happened in between the existing phases. Add these durations into the profile as "pre-X" phases so that user is aware of activities could still be happening during that time. RBE server implementation should be able to alter these label programmatically if necessary.
coeuvre
approved these changes
Dec 13, 2023
coeuvre
added
awaiting-PR-merge
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
|
@bazel-io fork 7.1.0 |
|
@bazel-io fork 6.5.0 |
bazel-io
removed
the
potential release blocker
github-actions
bot
removed
the
awaiting-PR-merge
iancha1992
pushed a commit
to iancha1992/bazel
that referenced
this pull request
Dec 14, 2023
After an action was executed remotely, RemoteSpawnRunner would use the timestamps in the execution metadata to record appropriate timing phases into the JSON profile. However, there are durations in-between the existing phases that are unaccounted for. Depending on the RBE server implemenation, these phases could mean different things: - Sandbox preparation - Cleaning up sandbox environments post-execution - Others Missing these durations inside the timing profile would cause confusion to end users as it would be interpreted as nothing happened in between the existing phases. Add these durations into the profile as "pre-X" phases so that user is aware of activities could still be happening during that time. RBE server implementation should be able to alter these label programmatically if necessary. Closes bazelbuild#20387. PiperOrigin-RevId: 590816782 Change-Id: I2bee36be928db24a14fab18bc519c3893723b7d6
github-merge-queue bot
pushed a commit
that referenced
this pull request
Dec 15, 2023
…20550) After an action was executed remotely, RemoteSpawnRunner would use the timestamps in the execution metadata to record appropriate timing phases into the JSON profile. However, there are durations in-between the existing phases that are unaccounted for. Depending on the RBE server implemenation, these phases could mean different things: - Sandbox preparation - Cleaning up sandbox environments post-execution - Others Missing these durations inside the timing profile would cause confusion to end users as it would be interpreted as nothing happened in between the existing phases. Add these durations into the profile as "pre-X" phases so that user is aware of activities could still be happening during that time. RBE server implementation should be able to alter these label programmatically if necessary. Closes #20387. Commit fe9e9e0 PiperOrigin-RevId: 590816782 Change-Id: I2bee36be928db24a14fab18bc519c3893723b7d6 Co-authored-by: Son Luong Ngoc <[email protected]>
bazel-io
pushed a commit
to bazel-io/bazel
that referenced
this pull request
Dec 21, 2023
After an action was executed remotely, RemoteSpawnRunner would use the timestamps in the execution metadata to record appropriate timing phases into the JSON profile. However, there are durations in-between the existing phases that are unaccounted for. Depending on the RBE server implemenation, these phases could mean different things: - Sandbox preparation - Cleaning up sandbox environments post-execution - Others Missing these durations inside the timing profile would cause confusion to end users as it would be interpreted as nothing happened in between the existing phases. Add these durations into the profile as "pre-X" phases so that user is aware of activities could still be happening during that time. RBE server implementation should be able to alter these label programmatically if necessary. Closes bazelbuild#20387. PiperOrigin-RevId: 590816782 Change-Id: I2bee36be928db24a14fab18bc519c3893723b7d6
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 11, 2024
…20647) After an action was executed remotely, RemoteSpawnRunner would use the timestamps in the execution metadata to record appropriate timing phases into the JSON profile. However, there are durations in-between the existing phases that are unaccounted for. Depending on the RBE server implemenation, these phases could mean different things: - Sandbox preparation - Cleaning up sandbox environments post-execution - Others Missing these durations inside the timing profile would cause confusion to end users as it would be interpreted as nothing happened in between the existing phases. Add these durations into the profile as "pre-X" phases so that user is aware of activities could still be happening during that time. RBE server implementation should be able to alter these label programmatically if necessary. Closes #20387. Commit fe9e9e0 PiperOrigin-RevId: 590816782 Change-Id: I2bee36be928db24a14fab18bc519c3893723b7d6 Co-authored-by: Son Luong Ngoc <[email protected]> Co-authored-by: Ian (Hee) Cha <[email protected]> Co-authored-by: Yun Peng <[email protected]>
|
The changes in this PR have been included in Bazel 6.5.0 RC1. Please test out the release candidate and report any issues as soon as possible. If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=last_rc. |
|
The changes in this PR have been included in Bazel 7.1.0 RC1. Please test out the release candidate and report any issues as soon as possible. If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=last_rc. |
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.
After an action was executed remotely, RemoteSpawnRunner would use
the timestamps in the execution metadata to record appropriate timing
phases into the JSON profile.
However, there are durations in-between the existing phases that are
unaccounted for. Depending on the RBE server implemenation, these
phases could mean different things:
Missing these durations inside the timing profile would cause confusion
to end users as it would be interpreted as nothing happened in between
the existing phases.
Add these durations into the profile as "pre-X" phases so that user is
aware of activities could still be happening during that time. RBE
server implementation should be able to alter these label
programmatically if necessary.