Skip to content

v20260817-220016

Choose a tag to compare

@github-actions github-actions released this 17 Aug 22:02
· 13 commits to main since this release
dfde978
[CRCR] Register the vLLM Buildkite pipeline (#8544)

```yaml
buildkite:
  018b5ec5-c236-4037-ba08-d8a5d29bcdae/018cdabc-d930-49f6-9085-634c4cb582ed:
    repo: vllm-project/vllm
    required_claims:
      build_branch: [main]
```

## Why

vLLM is adding a step to report its `Full CI run - torch nightly`
results to CRCR (vllm-project/vllm#51830) so a torch nightly that breaks
vLLM shows up on hud.pytorch.org/crcr. This file currently holds **only
commented-out examples**, so there is no Buildkite mapping at all — the
relay cannot resolve vLLM's OIDC token to a repo identity and rejects
every callback with 403.

That rejection would be **invisible**: every failure path in vLLM's
reporting script exits 0 and the step is `soft_fail: true`, by design so
reporting never gates the nightly. Green build, no rows.

## Constrained form, pinned to main

The `vllm/ci` pipeline builds fork PRs and any job in it can mint an
OIDC token, so this uses the constrained form the header prescribes
rather than the simple one. A fork PR must not be able to report as
`vllm-project/vllm`. vLLM's script also refuses to report off `main`
independently — defence in depth, but the relay-side constraint is the
one that actually binds.

## IDs are the immutable UUIDs, cross-checked

Per the header's warning that slugs are renameable and a released slug
can be claimed by another organization:

| | value | source |
| --- | --- | --- |
| organization_id | `018b5ec5-c236-4037-ba08-d8a5d29bcdae` | Buildkite
GraphQL `organization(slug: "vllm").uuid` |
| pipeline_id | `018cdabc-d930-49f6-9085-634c4cb582ed` | REST
`builds[].pipeline.id` **and** GraphQL `pipeline(slug: "vllm/ci").uuid`
— identical |

GraphQL also confirms that pipeline's repository is
`https://github.com/vllm-project/vllm.git`, so this is the right
pipeline and not a same-named one elsewhere.

## Verified against the relay's own resolver

Loaded the edited file with `jwt_helper.load_ci_provider_mappings` and
called `_extract_repo_buildkite` with realistic claim sets:

```
nightly on main        -> ALLOWED as vllm-project/vllm
fork PR branch         -> REJECTED (403, build_branch 'my-feature' not in allowed set)
missing build_branch   -> REJECTED (403, build_branch '' not in allowed set)
unregistered pipeline  -> REJECTED (403, pipeline ... is not registered with CRCR)
```

Existing suite still green: `tests/test_jwt_helper.py
tests/test_config.py tests/test_allowlist.py` — 30 passed.

## Rollout

The Lambda fetches this file at runtime via `CI_PROVIDERS_URL` and
caches it in Redis, so no redeployment is needed — it takes effect after
the cache TTL.

## Companion changes

- pytorch/pytorch#193837 adds `vllm-project/vllm` to the L2 allowlist,
which is what gives the rows a `downstream_repo_level` and puts them on
the HUD.
- vllm-project/vllm#51830 is the reporting step itself.
- Still outside any PR: `CRCR_CALLBACK_URL` and `BUILDKITE_API_TOKEN`
must be present in the vLLM pipeline or nightly-schedule environment.

Co-authored-by: Andrey Talman <atalman@users.noreply.github.com>