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
Design a strategy for secondary effects of builds (including lockfile generation) #12014
Comments
We already have some prior art here: writing report files with |
Sure, but those reports are arguably directly artifacts of running those goals. In the case of lockfiles, those goals (and a few others... |
While investigating #14885, it occurred to @tdyas and I that the workunit store and The primary challenge with collecting side-effects from workunits is that workunits do not tie very directly to the request node: and in particular, if something is re-tried or speculated, you would want to (transactionally) ignore all but the workunit for the successful node. So it's possible that this could use |
The side-effects of builds are currently applied-in and limited to
@goal_rule
s via access to theWorkspace
type. But there is a common case of side-effects which (rather than being the core reason for having run thegoal
, such as withfmt
/tailor
) are a "secondary" effect: lockfiles.In common usage, lockfiles are (re)generated automatically during the course of a build: i.e., if you were to run
./pants test x
after making an edit to a requirement, a lockfile would be updated as a secondary effect of the build.With the current design for side-effects, all goals which might cause a lockfile to be regenerated would need their signatures changed. On the one hand, this makes them more explicit: a goal without explicit support for lockfile handling (or at least a more abstract "affected files
Snapshot
" concept) would not support it. On the other hand, making side-effects explicit might be helpful, and improve reasoning about when they are applied (for example: thetest
goal could choose to apply effects regardless of whether some tests had failed, etc).An alternate design might involve explicitly supporting buffering up
Workspace.materialize_directory
calls (or their equivalent) in@rule
s (rather than only in@goal_rule
s, and applying them only if the entire request succeeds.The text was updated successfully, but these errors were encountered: