Repository navigation
Control of flag propagation through an exec cfg transition #28320
Description
Description of the feature request:
I am trying out the scope api in custom starlark flags with transitions. I would like to scope my key as "project", but I would also like to retain the flag setting over the exec transition - the flag controls behaviour both in the runtime of my target and also in the behaviour of some of my custom rules.
I discovered --experimental_propagate_custom_flag, but @fmeum pointed out that scopes are supposed to replace it.
(EDIT (twice) - it turns out that if I do all of: scope = "project", "experimental_propagate_custom_flags=//:my_flag" and "incompatible_exclude_starlark_flags_from_exec_config=true", then I get the behaviour I want, at least for my flag. That seems like a rather drastic change though, as who knows what other flags I'm suddenly resetting...
And in fact, with bazel 9.0.0rc6 if you have this combination of flags, and also have a rules_js target which goes through an exec transition, then you get a build failure in the postinstall hook of react with a file not found. If useful I can try to cook up a repro, just let me know.)
As it stands I believe I have to just be careful and not use "exec" in my code. Is that right, or have I missed something?
Thanks!
Which category does this issue belong to?
Configurability
What underlying problem are you trying to solve with this feature?
No response
Which operating system are you running Bazel on?
ubuntu
What is the output of bazel info release?
9.0.0rc6
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
Activity
fmeum commentedon Jan 16, 2026
@gregestren @aranguyen I think we talked about this before. Should we extend the API so that resetting on project boundaries and on exec transitions can be configured independently?
gregestren commentedon Jan 20, 2026
It's true the current
scopeAPI doesn't let you combine.Are you trying to model
//myproject:foo --exec_transition--> //myproject:tool --//other_project:dep? So the flag propagates until//other_project:dep?But with
//myproject:foo --> //other_project:dep --exec_transition--> //myproject:toolthe flag resets before the exec transition?In other words, are you comfortable with the invariant that a project-scoped flag propagates through an unbroken chain of project dependencies, but as soon as you leave the project it resets? And if it leaves the project before the exec transition then it won't get its value back in the exec config?
FYI
incompatible_exclude_starlark_flags_from_exec_config=trueis default for bazel@head. The only reason we didn't flip it for 9.0 was to give people more time to respond if their projects need updating. I wonder if you're finding examples of that.What do you mean here?
JonathanPerry651 commentedon Jan 21, 2026
Yes - this is exactly what I want. That's probably because I'm a 'leaf' repo, only consuming other repos (and thus never have the my project -> other project -> my project situation).
Interesting thank you
I think this story changes a bit with the point you made above that we think the rules_js behaviour will require remediation. So let's ignore that comment. But here's the overall setup of my world, I'd be grateful for a steer on how you would like me to model it in this API. I'm obviously super open to be told I'm misunderstanding the world:
So: I have code which generates yamls for my infra. It's essentially a compile step, .java -> .yaml. That code gets wired up through an executable = True, cfg = "exec" attr on a custom rule. The behaviour of that code is controlled by my label_flags above.
That code consumes the results of actions which build+push container images to my artifact repo. The behaviour of those containers also are controlled by my label_flags above. Those container images also contain rules_js code.
'Above' the generation code, the value of the label_flag is transitioned to point at configuration for the target environment.
So right now it goes like this:
Top level 'all environments' target (label_flag = 'unconfigured', 'target' config) -> Per target (label_flag = 'my env', 'target' config) -> Yaml generation binary (label_flag = 'my env', 'exec' config) -> Container image construction (label_flag = 'my env', 'exec' config) -> Java/Go/rules_js Application Code (label_flag = 'my env', 'exec' config)
There are several branches off that chain which go into external repos (rules_go, rules_js for example). Since I'm a leaf repo, those branches never return and cannot possibly be affected by my label_flag.
JonathanPerry651 commentedon Feb 21, 2026
@gregestren / @fmeum - did you have any further thoughts on this? I note it went to P2 which seems encouraging!
I'm hitting walls with my use of transitions, and am about to be forced into much sadder places, so I'd be very excited to hear any news :). For your info - the place I'm being forced to is I will have to move all my config resolution to the edges of my build graph, which will be really nasty - I'll have to late bind several java_binary targets and wrap them up in resolved config somehow, and repush container_images, rewriting hashes in my k8s config, and so forth.
Thank you
fmeum commentedon Feb 21, 2026
@gregestren With the current API, what do you think of introducing a
project_execscope (name TBD)? I would still prefer us collecting the full "algebraic data type" that a scope could really be and then determining the best way to specify the scope syntax-wise. This capability is still pretty new and there's value in getting the API in good shape.JonathanPerry651 commentedon Feb 23, 2026
I guess a hack around might be to use a custom_exec_scope_target, and then read both, preferring whichever is non-default
Edit - well that was a total misread of the branch of the codebase, so… off that
6 remaining items
gregestren commentedon Mar 20, 2026
Haven't forgotten - just lots of end of quarter attention demands. I'll schedule specific time next week to respond.
JonathanPerry651 commentedon Mar 23, 2026
Understood and much appreciated
gregestren commentedon Mar 25, 2026
Hi @JonathanPerry651 Re:
Can you clarify exactly what purpose
cfg = "exec"serves? I just want to double-check the core need.What I'm getting at is that while compiler tools need to be built in
"exec"configurations, they often run in target configurations. So a common pattern is a target-configured library will build a tool dependency in the"exec"config, then construct a target-configured action that runs the tool with whatever parameters make sense from the target configuration.So your java -> yaml binary: does building that binary require the
my_envsettings? Or can it be built independently of those settings, then integrated into an action that the target-configured "Per target" node creates, and the action can parameterize itself frommy_envfrom there?I realize the container image construction is a deeper dep. Not sure if that changes this analyses?
JonathanPerry651 commentedon Mar 25, 2026
@gregestren - thanks for looking. I think it would probably be possible to restructure the code this way for a subset of use cases, but two points.
One - to solve for all of them, I would basically end up back at the ‘late binding config’ state of the world, which becomes super intrusive and a nasty client api.
Two - I can’t be sure that I have actually covered everything: all it takes is a single stray “exec”, and suddenly I have the wrong configuration in production…
So I think if I could not rely on propagation through exec, I would have to switch to the manual late binding approach.
JonathanPerry651 commentedon Apr 1, 2026
@gregestren did that make sense? Is this an approach you see as interesting/useful?
Thanks!
gregestren commentedon Apr 3, 2026
How about updating the existing
"project"value to propagate through exec? I'd support that. There's no strong reason to break the existing setting at the exec boundary.JonathanPerry651 commentedon Apr 4, 2026
Love it. I’ll submit a PR asap. Thank you!
JonathanPerry651 commentedon Apr 5, 2026
@gregestren submitted. I think I cleaned it all up to be worth your review, but all feedback welcome. thanks again for your time!
Propagate project-scoped flags through exec transitions (#29232)
keith commentedon Jun 16, 2026
Is there a doc somewhere with the planned end state for all of this? I haven't seen
scope = "exec:--...mentioned anywheregregestren commentedon Jun 17, 2026
Did
scope = "exec:--//:host_modular_config",work for you?We wrote that a hack API and are hoping something more principled can evolve at some point down the line. That's the main reason for not publicizing it.
It also has some unintuitive technical limitations. I can't remember if it requires equivalent
--foo--host_fooflag aliases to properly work.keith commentedon Jun 17, 2026
Still testing to make sure but I believe it does. The issue otherwise for that repo is they're using that as a
compilation_modetype setting so if it is dropped through a second level exec transition you end up building artifacts in multiple configurations when you shouldn't be[9.2.0] Propagate project-scoped flags through exec transitions (baze…
iancha1992 commentedon Jun 26, 2026
This feature has been included in Bazel 9.2.0 RC1. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting
USE_BAZEL_VERSION=9.2.0rc1. Thanks!