-
Notifications
You must be signed in to change notification settings - Fork 4.5k
strict_action_env equivalent for repository rules #10996
Copy link
Copy link
Closed
Labels
P3We're not considering working on this, but happy to review a PR. (No assignee)We're not considering working on this, but happy to review a PR. (No assignee)not staleIssues or PRs that are inactive but not considered staleIssues or PRs that are inactive but not considered staleteam-ExternalDepsExternal dependency handling, remote repositiories, WORKSPACE file.External dependency handling, remote repositiories, WORKSPACE file.type: feature request
Metadata
Metadata
Assignees
Labels
P3We're not considering working on this, but happy to review a PR. (No assignee)We're not considering working on this, but happy to review a PR. (No assignee)not staleIssues or PRs that are inactive but not considered staleIssues or PRs that are inactive but not considered staleteam-ExternalDepsExternal dependency handling, remote repositiories, WORKSPACE file.External dependency handling, remote repositiories, WORKSPACE file.type: feature request
Description of the problem / feature request:
An equivalent of
--incompatible_strict_action_envthat affectsrepository_ctx.execute.Feature requests: what underlying problem are you trying to solve with this feature?
When I write repository rule implementations I often forget to declare the environment variables they depend on, so they are not reevaluated when those change, leading to incorrect builds, and requiring users to call
bazel clean --expungewhen the environment changes.I have tried to filter the environment down to what I need before passing it to
repository_ctx.execute, but the full environment is always added anyway:bazel/src/main/java/com/google/devtools/build/lib/bazel/repository/skylark/SkylarkRepositoryContext.java
Line 514 in 812cc59
A way to enforce the environment to be strict would be very helpful to avoid these kind of bugs in repository rules.
Have you found anything relevant by searching the web?
#7026