docs: require k8s-bake v4.1.1+ in the bake example (#555)

The bake example paired azure/k8s-bake@v3 with Azure/k8s-deploy@v7, which
cannot work. Since v7, assertPathWithinWorkspace rejects manifests that
resolve outside GITHUB_WORKSPACE, and k8s-bake before v4.1.1 wrote the
baked manifest to RUNNER_TEMP, a sibling of the workspace on hosted
runners. Copying the documented example produced:

  manifest path /home/runner/work/_temp/baked-template-<ts>.yaml resolves
  to ..., which is outside the workspace /home/runner/work/repo/repo

k8s-bake v4.1.1 writes into $GITHUB_WORKSPACE/.k8s-bake/ instead
(Azure/k8s-bake#289), so the chain works again with no change on the
k8s-deploy side. Bump the example to @v4 and state the minimum version,
since nothing in this repo currently tells users the bake upgrade is the
fix.

Refs #553
This commit is contained in:
Suneha Bose
2026-08-11 16:30:59 -07:00
committed by GitHub
parent 4fa6d56960
commit 75a6f522ba
+8 -1
View File
@@ -439,6 +439,13 @@ jobs:
### Use bake action to get manifests deploying to a Kubernetes cluster
> **Requires `azure/k8s-bake@v4.1.1` or later.** Since v7, `k8s-deploy` rejects
> `manifests:` paths that resolve outside `GITHUB_WORKSPACE`. Earlier versions of
> `k8s-bake` wrote the baked manifest to `RUNNER_TEMP`, which is a sibling of the
> workspace on hosted runners, so `manifestsBundle` was rejected. `k8s-bake` v4.1.1
> writes into the workspace instead ([Azure/k8s-bake#289](https://github.com/Azure/k8s-bake/pull/289)).
> Workflows that pass `manifestsBundle` need no other changes.
```yaml
on: [push]
env:
@@ -473,7 +480,7 @@ jobs:
container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
secret-name: demo-k8s-secret
- uses: azure/k8s-bake@v3
- uses: azure/k8s-bake@v4
with:
renderEngine: 'helm'
helmChart: './aks-helloworld/'