ci: auto-trigger aks-ai-runtime chart-integration-test on Ray PRs - #139
Alyssa Vu (alyssa1303) wants to merge 8 commits into
Conversation
images/ray's build recipe lives here, but the integration suite that validates it (AKS cluster, chart installs, e2e) runs in aks-ai-runtime's ADO pipelines. ADO repository-resource triggers only work for Azure Repos Git, not GitHub, so nothing there can react to a push here automatically. Add a workflow that queues aks-ai-runtime's chart-integration-test pipeline (id 470554) directly via the ADO REST API whenever a PR touches images/ray/**, passing the PR branch as the sourceRef template parameter, and comments on the PR with a link to the queued run. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace the PAT-gated "Run pipeline" REST API call with aks-ai-runtime's new TauGridRayImagePR incoming webhook resource. The org blocks Azure DevOps PAT creation, so ADO_PAT was never going to be usable here. The incoming webhook is authenticated with an HMAC-SHA1 signature over the request body (X-Hub-Signature header), keyed by a shared secret set on the Incoming WebHook service connection in the CloudNativeCompute ADO project -- not a PAT. Requires a repo secret ADO_WEBHOOK_SECRET matching that connection's secret. The webhook response doesn't reliably expose the queued run's ID, so the PR comment links to the pipeline's run list instead of one run. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Verifies the trigger-chart-integration-test.yml workflow fires end-to-end via GitHub Actions (path filter + webhook POST + PR comment) before merge. Safe to squash/drop at merge time.
|
🔄 Triggered chart-integration-test in aks-ai-runtime against this branch ( |
The signature header was built as GitHub-style "sha1=<lowercase hex>", based on two third-party blog posts. Microsoft's own docs for resources.webhooks.webhook give a concrete worked example showing the expected value is the bare uppercase hex digest with no prefix at all: 750D33212D3AD4932CC390819050734831A0A94F for a documented sample payload/secret pair. Reproduced that exact example locally to confirm. This explains the live test symptom: ADO returned 200 OK for our POST (likely returns 200 unconditionally to avoid leaking secret-guessing signal) but never actually queued a run, because the checksum never matched. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🔄 Triggered chart-integration-test in aks-ai-runtime against this branch ( |
|
🔄 Triggered chart-integration-test in aks-ai-runtime against this branch ( |
|
🔄 Triggered chart-integration-test in aks-ai-runtime against this branch ( |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🔄 Triggered chart-integration-test in aks-ai-runtime against this branch ( |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🔄 Triggered chart-integration-test in aks-ai-runtime against this branch ( |
1 participant
What
Adds a GitHub Actions workflow that auto-triggers aks-ai-runtime's
chart-integration-testADO pipeline (id470554) whenever a PR here touchesimages/ray/**, via that pipeline's newTauGridRayImagePRincoming webhook resource. Passes the PR branch assourceRefand comments on the PR once triggered.Why
images/ray's build recipe lives in this repo, but the integration suite that validates it (real AKS cluster, chart installs, e2e tests) runs in aks-ai-runtime's ADO pipelines. Azure DevOps repository-resource triggers only work for Azure Repos Git, not GitHub — so nothing in ADO can react automatically to a push here. Before this, validating a Ray image change required someone to remember to manually runchart-integration-test.ymlwith asourceRefoverride.This repo's org blocks Azure DevOps PAT creation, so the original design (calling ADO's authenticated "Run pipeline" REST API with a PAT) isn't usable here. Instead this calls aks-ai-runtime's
TauGridRayImagePRincoming webhook — a public ADO endpoint authenticated with an HMAC-SHA1 signature over the request body, not a PAT. See azure-management-and-platforms/aks-ai-runtime#1452 for the webhook resource +sourceRefcoalescing this depends on.Setup required before this is active
CloudNativeComputeproject (Project Settings → Service connections → New service connection → Incoming WebHook), a project admin creates a service connection:TauGridRayImagePR(must match exactly — it's the name in the pipeline'sresources.webhooksblock)X-Hub-Signaturechart-integration-testpipeline to use it (or check "Grant access permission to all pipelines")ADO_WEBHOOK_SECRET(Settings → Secrets and variables → Actions).chart-integration-test.ymlonce in ADO after the webhook resource is merged — new resource triggers need one normal run before ADO will accept webhook calls for them.Until the secret exists, the workflow fails fast with a clear error instead of silently no-oping.
Scope
This is intentionally "fire and forget" — it triggers the run and links to the pipeline's run list (the incoming-webhook response doesn't reliably expose a specific run ID), but doesn't report the result back as a status check yet. A reviewer still checks the ADO run before approving. A follow-up could add a callback so this becomes a required status check.