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
Handle workdir="."/default properly in run_shell_command (Cherry-pick of #18840) #18850
Merged
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
…18840) This fixes pantsbuild#18335 by updating `run_shell_command`'s `workdir` field to behave more like the same field in `shell_command`/`adhoc_tool`. In particular, previously `workdir="."` (including not setting `workdir` and using the default) was behaving like `workdir="/"`: running from the build root. Now, `workdir="."` (or no workdir arg) will run from the `BUILD` file's directory. This appears to have been a latent bug even with `experimental_run_shell_command` in 2.15 and before, not introduced as part of the stabilisation for 2.16: - running the test case from pantsbuild#18335 with 2.15.0 (having switched the targets) also exhibits the wrong behaviour, not matching the docs. - the behaviour change also affects 'simple' invocations like `run_shell_command(name="foo", command="bar")` without an explicit `workdir` field - looking at the two `experimental_run_shell_command` calls in our repo (neither of which set `workdir` explicitly), they'd be very slightly nicer with `workdir="."` behaviour, rather than the current `workdir="/"` behaviour The last point seems like weak evidence in doing the fix to match the documented behaviour, rather than trying to preserve the actual existing behaviour, but maybe it's worth mentioning the breaking change in the release notes?
kaos
approved these changes
Apr 28, 2023
chrisjrn
approved these changes
Apr 28, 2023
huonw
added a commit
that referenced
this pull request
Apr 30, 2023
This bumps up the timeouts of several tests that are regularly causing spurious failures: 1. `src/python/pants/init/load_backends_integration_test.py` 2. `src/python/pants/base/specs_integration_test.py` 3. `src/python/pants/backend/python/goals/coverage_py_integration_test.py` The most common of these is 1, especially for cherry-picks to 2.16. For instance, #18832 required 8 re-attempts, #18839 required 5 and #18850 got to 13. Given these seem to affect 2.16 cherry-picks so much, I'm thinking it makes sense to cherry pick this back to that branch too, along with the increase in #18847, and part of #18627 (the increase to `src/python/pants/engine/streaming_workunit_handler_integration_test.py`).
huonw
added a commit
to huonw/pants
that referenced
this pull request
Apr 30, 2023
This bumps up the timeouts of several tests that are regularly causing spurious failures: 1. `src/python/pants/init/load_backends_integration_test.py` 2. `src/python/pants/base/specs_integration_test.py` 3. `src/python/pants/backend/python/goals/coverage_py_integration_test.py` The most common of these is 1, especially for cherry-picks to 2.16. For instance, pantsbuild#18832 required 8 re-attempts, pantsbuild#18839 required 5 and pantsbuild#18850 got to 13. Given these seem to affect 2.16 cherry-picks so much, I'm thinking it makes sense to cherry pick this back to that branch too, along with the increase in pantsbuild#18847, and part of pantsbuild#18627 (the increase to `src/python/pants/engine/streaming_workunit_handler_integration_test.py`).
huonw
added a commit
that referenced
this pull request
Apr 30, 2023
#18859) This cherry-picks a bunch of test timeout increases from main to 2.16.x, to reduce the number of spurious re-attempts required for other cherry-picks. Fully cherry-picked: #18847, #18857 Partially cherry-picked (just the timeout increases): #18627, #18712. Motivation: when cherry-picking, #18832 required 8 re-attempts, #18839 required 5 and #18850 got to 13, almost all due to tests timing out. Various other cherry-picks likely required many re-attempts too. --------- Co-authored-by: Asher Foa <asher@toolchain.com>
huonw
added a commit
that referenced
this pull request
May 4, 2023
…ges (#18894) This does two minor doc tweaks related to the shell/adhoc tool work in 2.16: - the `adhoc_tool` docs had flipped the file vs directory for the `output_...` example (fixes #18890) - the `run_shell_command` workdir field (including its default behaviour) has changed in 2.16 (#18840, #18850), and this is added to the changelog, rather than migrated (quite hard #18860) or properly deprecated (also a bit awkward, and this is an `experimental_...` target)
huonw
added a commit
to huonw/pants
that referenced
this pull request
May 4, 2023
…ges (pantsbuild#18894) This does two minor doc tweaks related to the shell/adhoc tool work in 2.16: - the `adhoc_tool` docs had flipped the file vs directory for the `output_...` example (fixes pantsbuild#18890) - the `run_shell_command` workdir field (including its default behaviour) has changed in 2.16 (pantsbuild#18840, pantsbuild#18850), and this is added to the changelog, rather than migrated (quite hard pantsbuild#18860) or properly deprecated (also a bit awkward, and this is an `experimental_...` target)
huonw
added a commit
that referenced
this pull request
May 5, 2023
…ges (Cherry-pick of #18894) (#18910) This does two minor doc tweaks related to the shell/adhoc tool work in 2.16: - the `adhoc_tool` docs had flipped the file vs directory for the `output_...` example (fixes #18890) - the `run_shell_command` workdir field (including its default behaviour) has changed in 2.16 (#18840, #18850), and this is added to the changelog, rather than migrated (quite hard #18860) or properly deprecated (also a bit awkward, and this is an `experimental_...` target)
thejcannon
added a commit
to thejcannon/pants
that referenced
this pull request
May 6, 2023
…ges (pantsbuild#18894) This does two minor doc tweaks related to the shell/adhoc tool work in 2.16: - the `adhoc_tool` docs had flipped the file vs directory for the `output_...` example (fixes pantsbuild#18890) - the `run_shell_command` workdir field (including its default behaviour) has changed in 2.16 (pantsbuild#18840, pantsbuild#18850), and this is added to the changelog, rather than migrated (quite hard pantsbuild#18860) or properly deprecated (also a bit awkward, and this is an `experimental_...` target)
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.
This fixes #18335 by updating
run_shell_command
'sworkdir
field to behave more like the same field inshell_command
/adhoc_tool
. In particular, previouslyworkdir="."
(including not settingworkdir
and using the default) was behaving likeworkdir="/"
: running from the build root. Now,workdir="."
(or no workdir arg) will run from theBUILD
file's directory.This appears to have been a latent bug even with
experimental_run_shell_command
in 2.15 and before, not introduced as part of the stabilisation for 2.16:run_shell_command(name="foo", command="bar")
without an explicitworkdir
fieldexperimental_run_shell_command
calls in our repo (neither of which setworkdir
explicitly), they'd be very slightly nicer withworkdir="."
behaviour, rather than the currentworkdir="/"
behaviourThe last point seems like weak evidence in doing the fix to match the documented behaviour, rather than trying to preserve the actual existing behaviour, but maybe it's worth mentioning the breaking change in the release notes?