Last Updated:
AITER Pin
Which AITER commit the AMD images are built with, the PRs that moved it, and which AITER each CI run actually tested
Loading the AITER pin...
Pinned on main
What CI is testing
How the bump was tested
AITER Scout verdicts
| Run | AITER commit | Verdict | Memo |
|---|
Older verdicts
AITER changes in review
| PR | Change | AMD CI | Updated |
|---|
Pin changes
| Merged | PR | Change | AITER Scout verdict | AMD CI on the PR | First CI run on the new pin |
|---|
PR readiness
| Readiness | SGLang PR | AITER change | Feature | Listed under |
|---|
Every version in the tracker, as written
Which AITER each CI run tested
| Run | Workflow | Image | AITER tested | Pin on main then | Jobs passed |
|---|
AITER's own SGLang CI
Nightly suites 17:00 UTC, newest first
AITER main commits
| Pushed | Commit | Title | SGLang suites |
|---|
CI does not rebuild AITER to the pin:
amd_ci_install_dependency.sh keeps the AITER already
in the CI image whenever that image reports a dev build, so a new pin reaches tests only once CI picks
up the first nightly image built after the merge. "AITER tested" is read from the
[CI-AITER-CHECK] block in one job log per run and image. A cherry-pick keeps the base
commit, so a job log cannot tell which runs had one.
green the pin on main when the run started
amber an older pin, from an image built before the bump
blue AITER Scout's override, AITER main at the time