latest

Pass tenting ACL names from Buck2 to TPX via labels

Summary:
High level doc ( part 1 ): [RFC] ACL Metadata Propagation for Code Tenting by Michael Julio
Post: Code Tenting: Propagating ACL Tenting Metadata via Buck in Buck2 Dev by michaeljulio

Thread tenting ACL names through the Buck2 test pipeline and pass them to TPX
as labels on the ExternalRunnerSpec. This enables TPX to detect tented tests
and apply appropriate security policies.

**Details**
- In `interpret_targets`, query `TentingAclProvider` from DICE global data for
  each package path to get ACL names
- Thread `tenting_acl_names: Option<Vec<String>>` through all test pipeline
  stages: `ConfigureTarget` → `BuildTarget` → `TestTarget` → `dispatch()`
- In `build_external_runner_spec()`, JSON-encode all ACL names into a single
  label `tpx_test_config::tenting_acl_names=["<acl>", ...]` on the
  `ExternalRunnerSpec`. A single JSON-array label (not one label per ACL) is
  used because TPX reads the value via a single prefix match
  (`find_value_after_prefix`) and every downstream layer stores/decodes it as a
  JSON-encoded array string
- ACL names keep their full `REPO_REGION:` identity prefix exactly as returned
  by EdenFS `getAttributesFromFilesV2` in `AclEntry.repoRegionAcl`
- For targets discovered via the `tests` attribute, `tenting_acl_names` is set
  to `None` (they inherit their own package's tenting status independently)

Reviewed By: JakobDegen, lironmosh

Differential Revision: D104053830

fbshipit-source-id: 21665cef9e6548878e16f4d7e9373647f7ffc28f

2026-07-02

Pass tenting ACL names from Buck2 to TPX via labels

Summary:
High level doc ( part 1 ): [RFC] ACL Metadata Propagation for Code Tenting by Michael Julio
Post: Code Tenting: Propagating ACL Tenting Metadata via Buck in Buck2 Dev by michaeljulio

Thread tenting ACL names through the Buck2 test pipeline and pass them to TPX
as labels on the ExternalRunnerSpec. This enables TPX to detect tented tests
and apply appropriate security policies.

**Details**
- In `interpret_targets`, query `TentingAclProvider` from DICE global data for
  each package path to get ACL names
- Thread `tenting_acl_names: Option<Vec<String>>` through all test pipeline
  stages: `ConfigureTarget` → `BuildTarget` → `TestTarget` → `dispatch()`
- In `build_external_runner_spec()`, JSON-encode all ACL names into a single
  label `tpx_test_config::tenting_acl_names=["<acl>", ...]` on the
  `ExternalRunnerSpec`. A single JSON-array label (not one label per ACL) is
  used because TPX reads the value via a single prefix match
  (`find_value_after_prefix`) and every downstream layer stores/decodes it as a
  JSON-encoded array string
- ACL names keep their full `REPO_REGION:` identity prefix exactly as returned
  by EdenFS `getAttributesFromFilesV2` in `AclEntry.repoRegionAcl`
- For targets discovered via the `tests` attribute, `tenting_acl_names` is set
  to `None` (they inherit their own package's tenting status independently)

Reviewed By: JakobDegen, lironmosh

Differential Revision: D104053830

fbshipit-source-id: 21665cef9e6548878e16f4d7e9373647f7ffc28f

2026-05-31

use a connection pool for remote execution (#1213)

Summary:
Implement a connection pool for all remote APIs.  This can be configured using min_connections, max_connections, and max_concurrency_per_connection.  It roughly is a round robin algorithm, and the connection pool can grow when connections are maxed out with requests.  Once all connections are maxed out, the pool gives out channels that will provide back pressure when they are attempted to be used.

Pull Request resolved: https://github.com/facebook/buck2/pull/1213

Reviewed By: christolliday, ndmitchell, Nero5023

Differential Revision: D91266586

Pulled By: scottcao

fbshipit-source-id: 609ffe24ebe83e061da6f151b189daa8112bd065

2026-01-31

Add marker to all exec platform registrations

Summary:
RFC: https://fb.workplace.com/groups/buck2dev/permalink/4179858482302192/

 ---

This diff adds the `exec_marker_constraint` to all existing `ExecutionPlatformRegistrationInfo` usages.

This ensures all registered execution platforms will have the marker constraint injected into their configuration.

The added function also try to read the root config `[build].exec_platform_marker`, if user want to define their own maker, they can deine that.

Reviewed By: scottcao

Differential Revision: D90713790

fbshipit-source-id: 26f43a41a26b451ec994aa1e449caddeeb9bbe14

2026-01-08

Stop inserting ovr_config//build_mode:sanitizer_type[no-san] into gen…