10/13 EDIT

Proposal to extend the exec groups API to allow exec groups to inherit requirements from the rule. Extending from other exec groups may happen if there's a documented need in the future.

# instead of duplicating the toolchains and constraints of the rule like so:
my_rule = rule(
  implementation = _impl,
  toolchains = ["//my/toolchain/type"],
  exec_compatible_with = ["//my/constraint"],
  exec_groups = {
   "foo": exec_group(
       toolchains = ["//my/toolchain/type"],
       exec_compatible_with = ["//my/constraint"],
   ),  
 }
)

# use the `copy_from_rule` attribute which will automatically use the toolchains and constraints
# from the rule:
my_rule = rule(
  implementation = _impl,
  toolchains = ["//my/toolchain/type"],
  exec_compatible_with = ["//my/constraint"],
  exec_groups = {
    "foo": exec_group(
      copy_from_rule = true, # it is an error to set this parameter and set toolchains or constraints
    ),  
  }
)

Advantages over original proposal:

• Doesn't imply complicated situations with the word "inheritance"
• Doesn't prevent the exec group "rule" from being created
• Tells exactly what it does.

Disadvantages over original proposal:

• Less extensible if we want to be able to copy from other exec groups in the future. But let's not design for features we don't have a documented need for yet.

ORIGINAL PROPOSAL

Proposal to extend the exec groups API to allow exec groups to inherit requirements from either other exec groups or the rule.

Allowing exec groups to declare "I have the same toolchains and constraints as the rule to which I'm attached" is helpful to create exec groups that are just for setting per-action execution requirements via exec_properties. It will be done via an inherits param to the exec_group constructor method. For example:

# defs.bzl
def _impl(ctx):
  ctx.actions.run(
    exec_group = "foo",
    ...
  )
  ctx.actions.run(
    //no exec_group set
    ...
  )
  ...

my_rule = rule(
  implementation = _impl,
  toolchains = ["//my/toolchain/type"],
  exec_compatible_with = ["//my/constraint"],
  exec_groups = {
   "foo": exec_group(inherits = "rule")   
 }
)

# BUILD
load(":defs.bzl", "my_rule")
my_rule(
  name = "my-target",
  exec_properties = {
    "foo.mem": "20g",
  }
)

This example shows how you can allocate extra (20g) memory to a specific action without allocating it to all the actions. The inherits param to the exec group is a nice convenience so that the exec group doesn't have to copy over the rule's toolchains and constraints. It's more true to what the rule author is trying to express and also isn't liable to people forgetting to update if they're updating the rule's toolchains/constraints.

The inherits param can also take the name of another exec group on the same rule. This will allow exec groups to to resolve to more specific platforms of other exec groups. The list of toolchains for an exec group that inherits from another rule will the be other exec group's toolchains + the toolchains explicitly listed for this exec group.

If the inherits param is given a string other than "rule" (which is a banned exec group name) or another exec group on the same rule, it will error out.

This will help resolve #10799 and replace #10866 with exec groups instead of a brand new attribute. We will implement a "test" exec group that inherits from whatever rule it's on and can be set via the standard exec_properties attr.