Let users specify the total build timeout using `/buildTimeoutMins`. Before this PR the only way was via an engine env var (the CB runner uses this).
Deprecate /BuildWaitTimeout CLI. This flag (unrelated to the functionality being added here) is not being used and it has a confusing name given the new flag being added.
Allow users to specify reclassifications on operations resolved by the observed input processor. Users can configure rules in their specification that individual pips can opt into, where some observation types are reclassified after being processed by the observed input processor.
The rule matching happens both after execution and when processing pathsets for the pip on cache lookup. Future optimizations might avoid some of the processings on cache lookup.
Note that any changes in these rules results in a weak fingerprint change for the pips, as there is no way to know if observations for the pip have to be reclassified with the new rules.
To learn more about the motivations for this change, refer to [this document](https://microsoft.sharepoint.com/:w:/t/1ES2/EXOegdiLQkRNt5bE7nhFic8BJBYKcETrqcY-gI2_jTN9zw?e=UEIxAg)
Related work items: #2185890
This arg controls whether buildxl warns about spotlight (macOS's file indexer) potentially acting on build directories. Removing the arg and functionality for simplification.
There are a bunch of other discrepancies between BuildXL's command line and the names given to consts in strings.resx, which is what is used to generate Flags.md.
The script that generates Flags.md works directly off of strings.resx. I doubt a pass was ever down when that script was created to ensure strings.resx actually matched up with the command line. This change would be better if it included some guardrails to prevent the two from skewing again in the future, but I don't think the cost/benefit is there so I'm just doing a one-time cleanup pass.
Remove macOS sandbox / kernel extension code and examples. Trying to only remove dead code here, some refactoring is still possible to improve code structure but I will leave it for future PRs.
Remove the condition where customers need to pass this parameter in the AllowList entries.
Reused two unit tests which test this feature.
Had to define a comparer for comparing SerializableRegex objects since it was becoming an issue when using the MultiValueDictionary to extract elements.
Related work items: #2139864
The step to publish the external npm package has been removed already. This PR removes the external package from our sources (the publish step was pointing to it).
Related work items: #2168692
We need this for servicing due to an office incident where the existing salt can only be set once. Instead of doing something one-off, I elected to wire up this long forgotten parameter with the semantics needed for the incident. It can be documented in help text now too.
Add minimal but self-contained documentation for using BuildXL with CMake and Ninja projects. Update the examples to reflect the recommended way to run CMake projects using Ninja generation, and marking the CMake resolver example as experimental and unsupported
Related work items: #2125879
- PipProperties made it into the flags.md file but not into buildxl's actual help text. Add it to help text
- Rename PipFingerprintingSalt to drop the "ing" which better aligns with related terminology in BuildXL
- Add platform agnostic support for newlines in help text and generated markdown documentation
Related work items: #2131602
BuildXL looks up cache miss data based on a priority list of keys configured by the user. In practice, the best general setup is to use a chain of git parent commits. This gets replicated in logic that invokes bxl.exe today for some of our customers. This PR provides this as a default experience without the end user needing to manually perform it.
The approach is heuristic, trying to pick candidate keys that might have been used to publish a fingerprint store for a build as "close" as the one running.
For this, the candidates are picked by
1. Get latest 5 commits from the current HEAD. We should get a match if this branch was built before, for example for a PR we expect one build per 'iteration'. Because an iteration can have multiple commits, we should not use a very small number (like, say, this commit and the one before), but let's not go overboard either (hence 5).
2. For any additional additional branches (indicated by the user in the argument), the assumption is that they run build against every commit (this should typically be the `main` branch, or the target branch for a PR).
a) We retrieve the merge-base from HEAD and that branch. We use as keys the hashes for the 3 commits immediately previous to the merge-base.
b) Finally, as a last resort, we use the latest 3 hashes from that branch as a last resort, assuming again that it was built recently
An example: for a PR (that has branched from `h5` and committed a number of times) merging against main, with this topology:
```
.--b5--b4--b3--b2--b1-- b0 [PR branch]
/
h8 -- h7 --h6--- h5 -- h4 -- h3 -- h2 -- h1 -- h0 [main]
```
The hashes for the keys would be (as described above)
1)`b0, b1, b2, b3, b4, b5`
2a) `h5, h6, h7`
2b) `h0, h1, h2`
Duplicates are removed, so something like this:
```
.--b1-- b0 [PR branch]
/
h8 -- h7 --h6--- h5 -- h1 -- h0 [main]
```
would result in the cadidates being `b0, b1, h5, h6, h7, h0, h1`.
Related work items: #2116194
``*`` used in the document to mention about a special use case has been parsed as a formatting symbol. Hence corrected the representation of it.
Related work items: #2104560
Michael Pysson
Serge Mera
Qi Wang
Marcelo Lynch 🧉
Oleksii Kononenko
Pasindu Gunasekara 🍣
Semih Okur
Iman Narasamdya
Sahiti Chandramouli
