Skip to content
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

Resolve adhoc_tool, code_quality_tool execution dependencies relative to target location #20581

Merged
merged 3 commits into from
Feb 25, 2024

Conversation

huonw
Copy link
Contributor

@huonw huonw commented Feb 19, 2024

This PR fixes #20575 by adjusting the shared infrastructure for adhoc_tool and code_quality_tool to resolve the execution_dependencies field relative to the adhoc_tool/code_quality_tool target location, rather than relative to the runnable=... arg. I think this was a minor typo in #20255, and we didn't have tests covering it.

I imagine it's common that the runnable and ..._tool targets are often in the same BUILD file (in which case the behaviour is the same either way), but it's not impossible to have them be different (e.g. my work repo has a a few shared runnable that are used by more than one adhoc_tool). I think being relative to the target is easier to reason about, and this was the old behaviour of adhoc_tool.

This PR also adds tests to confirm the behaviour of execution_dependencies (including its relative-path resolution behaviour), as well as the behaviour of runnable_dependencies while I'm there.

@huonw huonw added needs-cherrypick category:bugfix Bug fixes for released features labels Feb 19, 2024
@huonw huonw added this to the 2.20.x milestone Feb 19, 2024
@huonw huonw changed the title Resolve adhoc_tool, code_quality_tool relative to target location Resolve adhoc_tool, code_quality_tool execution dependencies relative to target location Feb 19, 2024
@huonw

This comment was marked as resolved.

@huonw huonw force-pushed the huonw/20575-address branch from 40f0635 to 40c30fb Compare February 22, 2024 06:24
@huonw huonw marked this pull request as ready for review February 22, 2024 09:53
@huonw huonw merged commit a118143 into main Feb 25, 2024
24 checks passed
@huonw huonw deleted the huonw/20575-address branch February 25, 2024 23:21
WorkerPants pushed a commit that referenced this pull request Feb 25, 2024
… to target location (#20581)

This PR fixes #20575 by adjusting the shared infrastructure for
`adhoc_tool` and `code_quality_tool` to resolve the
`execution_dependencies` field relative to the
`adhoc_tool`/`code_quality_tool` target location, rather than relative
to the `runnable=...` arg. I think this was a minor typo in #20255, and
we didn't have tests covering it.

I imagine it's common that the runnable and `..._tool` targets are often
in the same BUILD file (in which case the behaviour is the same either
way), but it's not impossible to have them be different (e.g. my work
repo has a a few shared runnable that are used by more than one
`adhoc_tool`). I think being relative to the target is easier to reason
about, and this was the old behaviour of `adhoc_tool`.

This PR also adds tests to confirm the behaviour of
`execution_dependencies` (including its relative-path resolution
behaviour), as well as the behaviour of `runnable_dependencies` while
I'm there.
@WorkerPants
Copy link
Member

I tried to automatically cherry-pick this change back to each relevant milestone, so that it is available in those older releases of Pants.

✔️ 2.20.x

Successfully opened #20608.


Thanks again for your contributions!

🤖 Beep Boop here's my run link

huonw added a commit that referenced this pull request Feb 26, 2024
… to target location (Cherry-pick of #20581) (#20608)

This PR fixes #20575 by adjusting the shared infrastructure for
`adhoc_tool` and `code_quality_tool` to resolve the
`execution_dependencies` field relative to the
`adhoc_tool`/`code_quality_tool` target location, rather than relative
to the `runnable=...` arg. I think this was a minor typo in #20255, and
we didn't have tests covering it.

I imagine it's common that the runnable and `..._tool` targets are often
in the same BUILD file (in which case the behaviour is the same either
way), but it's not impossible to have them be different (e.g. my work
repo has a a few shared runnable that are used by more than one
`adhoc_tool`). I think being relative to the target is easier to reason
about, and this was the old behaviour of `adhoc_tool`.

This PR also adds tests to confirm the behaviour of
`execution_dependencies` (including its relative-path resolution
behaviour), as well as the behaviour of `runnable_dependencies` while
I'm there.

Co-authored-by: Huon Wilson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:bugfix Bug fixes for released features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2.20 changes adhoc_tool to resolve target specs in execution_dependencies relative to runnable, not target
3 participants