-
-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow bazel run @maven//:pin
to run successfully
#426
Conversation
To do this, we download each version of jq that might be used and ensure it's available. Decide at run time which version we'll use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Hmm, this isn't working for me
Changing this arg We go to lengths to genrule-copy the file to just "jq" so it doesn't seem like we should have to do this? unless it's for windows, but then you still don't have a bash.runfiles helper used in the pin.sh script |
Problem reported on bazel-contrib#426 The build typically takes place in the user's workspace, so using `$(location)` (or more correctly, `$(rootpath)`) gives an undesirable "external/" leading segment. This would be useful if the binary being run is in the users workspace, but we know our binary is in the same workspace defining the BUILD file. This change also uses the runfiles helper since I think that's required to make this work on Windows, though I only tested on Mac.
Problem reported on bazel-contrib#426 The build typically takes place in the user's workspace, so using `$(location)` (or more correctly, `$(rootpath)`) gives an undesirable "external/" leading segment. This would be useful if the binary being run is in the users workspace, but we know our binary is in the same workspace defining the BUILD file. This change also uses the runfiles helper since I think that's required to make this work on Windows, though I only tested on Mac.
It currently relies on the legacy_external_runfiles behavior where Bazel makes two copies of the program, at both pin.runfiles/unpinned_maven/jq and pin.runfiles/user_repo/external/unpinned_maven/jq Problem reported on bazel-contrib#426
It currently relies on the legacy_external_runfiles behavior where Bazel makes two copies of the program, at both pin.runfiles/unpinned_maven/jq and pin.runfiles/user_repo/external/unpinned_maven/jq Problem reported on bazel-contrib#426
It currently relies on the legacy_external_runfiles behavior where Bazel makes two copies of the program, at both pin.runfiles/unpinned_maven/jq and pin.runfiles/user_repo/external/unpinned_maven/jq Problem reported on #426
To do this, we download each version of jq that might be used and
ensure it's available. Decide at run time which version we'll use.
Fixes #409