Kubernetes bake action

Use this action to bake manifest files to be used for deployments using helm, kustomize or kompose.

Sets output variable 'manifestsBundle' which contains the location of the manifest bundles created by bake action.

Example

Bake using helm

- uses: azure/k8s-bake@v4
   with:
      renderEngine: 'helm'
      helmChart: './aks-helloworld/'
      arguments: |
          --ca-file
          ./ca-file/
      overrideFiles: './aks-helloworld/values-override.yaml'
      overrides: |
          replicas:2
      helm-version: '^3.0.0' # Use 'latest' to get the latest stable release (may include breaking changes across major versions)
      silent: 'false'

Helm Version Selection

The helm-version input supports semver-compatible version ranges. This is useful for ensuring compatibility while allowing automatic updates within a major version.

Examples:

• ^3.0.0 - Use the latest helm v3.x.x release (default). This avoids breaking changes that may occur with helm v4.
• ~3.12.0 - Use the latest helm v3.12.x patch release
• v3.12.1 - Use an exact version
• latest - Use the latest stable release (may include breaking changes across major versions)

Bake using Kompose

- uses: azure/k8s-bake@v4
  with:
     renderEngine: 'kompose'
     dockerComposeFile: './docker-compose.yml'
     kompose-version: 'latest'

Bake using Kubernetes Kustomize

- uses: azure/k8s-bake@v4
  with:
     renderEngine: 'kustomize'
     kustomizationPath: './kustomizeexample/'
     arguments: |
        --ca-file
        ./ca-file/
     kubectl-version: 'latest'

Refer to the action metadata file for details about all the inputs.

Output location

The baked manifest is written to a .k8s-bake directory inside GITHUB_WORKSPACE, and its full path is exposed as the manifestsBundle output. The manifest is removed at the end of the job, along with the directory if nothing else is in it.

Always consume the result through the output variable rather than hardcoding a path:

manifests: ${{ steps.bake.outputs.manifestsBundle }}

If your workflow checks for an unmodified checkout part way through the job, add the directory to your .gitignore:

.k8s-bake/

Note. Earlier versions wrote to RUNNER_TEMP, which sits outside GITHUB_WORKSPACE. k8s-deploy v7 rejects manifests that resolve outside the workspace, so bake output could no longer be deployed (#286). Workflows that read manifestsBundle need no changes.

End to end workflow for building container images and deploying to a Kubernetes cluster

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - uses: actions/checkout@v7

         - uses: Azure/docker-login@v2
           with:
              login-server: contoso.azurecr.io
              username: ${{ secrets.REGISTRY_USERNAME }}
              password: ${{ secrets.REGISTRY_PASSWORD }}

         - run: |
              docker build . -t contoso.azurecr.io/k8sdemo:${{ github.sha }}
              docker push contoso.azurecr.io/k8sdemo:${{ github.sha }}

         - uses: Azure/k8s-set-context@v5
           with:
              kubeconfig: ${{ secrets.KUBE_CONFIG }}

         - uses: Azure/k8s-create-secret@v6
           with:
              container-registry-url: contoso.azurecr.io
              container-registry-username: ${{ secrets.REGISTRY_USERNAME }}
              container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
              secret-name: demo-k8s-secret

         - uses: azure/k8s-bake@v4
           with:
              renderEngine: 'helm'
              helmChart: './aks-helloworld/'
              overrideFiles: './aks-helloworld/values-override.yaml'
              overrides: |
                 replicas:2
              helm-version: 'latest'
           id: bake

         - uses: Azure/k8s-deploy@v7
           with:
              manifests: ${{ steps.bake.outputs.manifestsBundle }}
              images: |
                 demo.azurecr.io/k8sdemo:${{ github.sha }}
              imagepullsecrets: |
                 demo-k8s-secret

Development

This repository enforces a 7-day dependency freshness ("bake") period: newly published npm packages are not adopted until they have been available for at least 7 days, giving the ecosystem time to catch broken or malicious releases.

• Dependabot uses a 7-day cooldown and opens PRs on the 1st and 15th of each month, grouping minor/patch updates into a single PR. Major updates are still raised individually so they get their own review.
• .npmrc sets min-release-age=7 (days), which applies the same rule to local npm install. This requires npm >= 11.10.0; the version bundled with Node 24 (this action's runtime) satisfies that. On older npm the setting is ignored, so Dependabot's cooldown remains the authoritative control.

Security exception: to adopt an urgent patch that is less than 7 days old, install it once with the age check disabled:

npm install <pkg> --min-release-age=0

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Support

k8s-bake is an open source project that is not covered by the Microsoft Azure support policy. Please search open issues here, and if your issue isn't already represented please open a new one. The project maintainers will respond to the best of their abilities.