Fix corner cases in Bash runfiles library #16945
Closed
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
|
@Wyverald Could you review? FYI @meteorcloudy |
fmeum
force-pushed
the
16933-bash-runfiles-lib-rbe
branch
2 times, most recently
from
21c9f95
to
e61f458
Compare
sgowroji
added
team-ExternalDeps
fmeum
force-pushed
the
16933-bash-runfiles-lib-rbe
branch
from
e61f458
to
47cd403
Compare
fmeum
force-pushed
the
16933-bash-runfiles-lib-rbe
branch
3 times, most recently
from
f7d0158
to
46bdc3a
Compare
|
I don't understand the CI failure yet. |
|
Looks okay to me, pending failures. @ahumesky any Android comments? |
Seems fishy... why shouldn't it be found? I have a couple questions about this PR:
|
ted-xie
requested changes
Dec 8, 2022
It looks like only a few tests declare
These are going away, I am just (ab)using CI to debug issues on Windows.
No, the incantation has remained compatible with the new version 3 of the runfiles library. |
fmeum
force-pushed
the
16933-bash-runfiles-lib-rbe
branch
from
46bdc3a
to
d013c6c
Compare
fmeum
requested review from
ted-xie
and removed request for
gregestren and
fweikert
|
Downstream test for this change: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2775 |
|
@meteorcloudy is the original author of the runfiles macro so I think he's the most qualified to give the final review here. No concerns from the Android side for me, as long as all the existing tests pass in presubmit. |
Due to tests not actually verifying the exit code of rlocation calls, a few special cases were not handled correctly. In particular, absolute paths still went through regular rlocation lookup and could fail there even after the absolute path had been printed to stdout. Also adds a missing newline in the (very rare) case that a manifest entry is found, but doesn't point to an existing file (e.g. if it is an unresolved symlink), and `rlocation` is not used with command substitution, but some other mechanism that doesn't strip trailing newlines. The tests now assert the expected exit code (== 0 or != 0). Fixes bazelbuild#16933
fmeum
force-pushed
the
16933-bash-runfiles-lib-rbe
branch
from
d013c6c
to
027ac02
Compare
|
@meteorcloudy Looks like presubmit failed due to CI overload. I amended without changes to rerun the pipeline. |
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
Wyverald
approved these changes
Dec 8, 2022
|
Downstream test results look good: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2775#_ |
Wyverald
added
awaiting-PR-merge
meteorcloudy
approved these changes
Dec 9, 2022
sgowroji
removed
the
awaiting-PR-merge
fmeum
added a commit
to fmeum/bazel
that referenced
this pull request
Dec 12, 2022
Due to tests not actually verifying the exit code of rlocation calls, a few special cases were not handled correctly. In particular, absolute paths still went through regular rlocation lookup and could fail there even after the absolute path had been printed to stdout. Also adds a missing newline in the (very rare) case that a manifest entry is found, but doesn't point to an existing file (e.g. if it is an unresolved symlink), and `rlocation` is not used with command substitution, but some other mechanism that doesn't strip trailing newlines. The tests now assert the expected exit code (== 0 or != 0). Fixes bazelbuild#16933 Closes bazelbuild#16945. PiperOrigin-RevId: 494609104 Change-Id: I30333219176a61bda51f08c2c6bc927ce653d681
meteorcloudy
pushed a commit
that referenced
this pull request
Dec 12, 2022
Due to tests not actually verifying the exit code of rlocation calls, a few special cases were not handled correctly. In particular, absolute paths still went through regular rlocation lookup and could fail there even after the absolute path had been printed to stdout. Also adds a missing newline in the (very rare) case that a manifest entry is found, but doesn't point to an existing file (e.g. if it is an unresolved symlink), and `rlocation` is not used with command substitution, but some other mechanism that doesn't strip trailing newlines. The tests now assert the expected exit code (== 0 or != 0). Fixes #16933 Closes #16945. PiperOrigin-RevId: 494609104 Change-Id: I30333219176a61bda51f08c2c6bc927ce653d681
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.
Due to tests not actually verifying the exit code of rlocation calls, a few special cases were not handled correctly. In particular, absolute paths still went through regular rlocation lookup and could fail there even after the absolute path had been printed to stdout.
Also adds a missing newline in the (very rare) case that a manifest entry is found, but doesn't point to an existing file (e.g. if it is an unresolved symlink), and
rlocationis not used with command substitution, but some other mechanism that doesn't strip trailing newlines.The tests now assert the expected exit code (== 0 or != 0).
Fixes #16933