From 8b194fc51139eae20b9403da429886a4b9e15029 Mon Sep 17 00:00:00 2001
From: Yuval <yuvalk@gmail.com>
Date: Sat, 6 Mar 2021 19:57:28 +0200
Subject: [PATCH 1/2] Documentation for #13110

---
 site/docs/exec-groups.md | 41 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/site/docs/exec-groups.md b/site/docs/exec-groups.md
index f9a6bfb89d213d..b381bbb33be793 100644
--- a/site/docs/exec-groups.md
+++ b/site/docs/exec-groups.md
@@ -132,6 +132,14 @@ All actions with `exec_group = "link"` would see the exec properties
 dictionary as `{"mem": "16g"}`. As you see here, execution-group-level
 settings override target-level settings.
 
+### Execution groups for native rules
+
+Currently, the following execution groups are available for actions defined by
+native rules:
+
+* `test`: Test runner actions.
+* `cpp_link`: C++ linking actions.
+
 ### Creating exec groups to set exec properties
 
 Sometimes you want to use an exec group to give specific actions different exec
@@ -162,3 +170,36 @@ my_rule = rule(
 #
 ```
 
+### Execution groups and platform execution properties
+
+It is possible to define `exec_properties` for arbitrary execution groups on
+platform targets (unlike `exec_properties` set directly on a target, where
+properties for unknown execution groups are rejected). Targets then inherit the
+platform's `exec_properties` that affect the default execution group and any
+other relevant execution groups.
+
+For example, suppose running a C++ test requires some resource to be available,
+but it isn't required for compiling and linking; this can be modelled as
+follows:
+
+```python
+constraint_setting(name = "resource")
+constraint_value(name = "has_resource", constraint_setting = ":resource")
+
+platform(
+    name = "platform_with_resource",
+    constraint_values = [":has_resource"],
+    exec_properties = {
+        "test.resource": "...",
+    },
+)
+
+cc_test(
+    name = "my_test",
+    srcs = ["my_test.cc"],
+    exec_compatible_with = [":has_resource"],
+)
+```
+
+`exec_properties` defined directly on targets take precedence over those that
+are inherited from the platform.

From 8a9ca0274c46669ad62634ac57281a37d98bde61 Mon Sep 17 00:00:00 2001
From: Yuval Kaplan <yuvalk@gmail.com>
Date: Mon, 8 Mar 2021 18:27:39 +0200
Subject: [PATCH 2/2] Clarify that exec_properties are inherited from the exec
 platform.

---
 site/docs/exec-groups.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/site/docs/exec-groups.md b/site/docs/exec-groups.md
index b381bbb33be793..3a3b10c1273494 100644
--- a/site/docs/exec-groups.md
+++ b/site/docs/exec-groups.md
@@ -175,8 +175,8 @@ my_rule = rule(
 It is possible to define `exec_properties` for arbitrary execution groups on
 platform targets (unlike `exec_properties` set directly on a target, where
 properties for unknown execution groups are rejected). Targets then inherit the
-platform's `exec_properties` that affect the default execution group and any
-other relevant execution groups.
+execution platform's `exec_properties` that affect the default execution group
+and any other relevant execution groups.
 
 For example, suppose running a C++ test requires some resource to be available,
 but it isn't required for compiling and linking; this can be modelled as
@@ -202,4 +202,4 @@ cc_test(
 ```
 
 `exec_properties` defined directly on targets take precedence over those that
-are inherited from the platform.
+are inherited from the execution platform.