This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [azure/k8s-deploy](https://github.com/azure/k8s-deploy) | action | major | `v5.1.0` → `v6.0.0` | --- ### Release Notes <details> <summary>azure/k8s-deploy (azure/k8s-deploy)</summary> ### [`v6.0.0`](https://github.com/Azure/k8s-deploy/releases/tag/v6.0.0) [Compare Source](https://github.com/azure/k8s-deploy/compare/v5.1.0...v6.0.0) ##### Changed - [#​504](https://github.com/azure/k8s-deploy/issues/504) [Update Node.js runtime from node20 to node24](https://github.com/Azure/k8s-deploy/pull/504) - [#​500](https://github.com/azure/k8s-deploy/issues/500) [Update action version references in README to latest majors](https://github.com/Azure/k8s-deploy/pull/500) ##### Security - [#​506](https://github.com/azure/k8s-deploy/issues/506) [Bump undici from 6.23.0 to 6.24.1](https://github.com/Azure/k8s-deploy/pull/506) - [#​513](https://github.com/azure/k8s-deploy/issues/513) [Bump vite from 8.0.3 to 8.0.5](https://github.com/Azure/k8s-deploy/pull/513) - [#​509](https://github.com/azure/k8s-deploy/issues/509) [Bump the actions group across 1 directory with 4 updates](https://github.com/Azure/k8s-deploy/pull/509) - [#​510](https://github.com/azure/k8s-deploy/issues/510) [Bump the actions group across 1 directory with 2 updates](https://github.com/Azure/k8s-deploy/pull/510) - [#​511](https://github.com/azure/k8s-deploy/issues/511) [Bump vitest from 4.1.1 to 4.1.2](https://github.com/Azure/k8s-deploy/pull/511) - [#​514](https://github.com/azure/k8s-deploy/issues/514) [Bump the actions group with 2 updates](https://github.com/Azure/k8s-deploy/pull/514) - [#​501](https://github.com/azure/k8s-deploy/issues/501) [Bump @​types/node from 25.3.3 to 25.4.0](https://github.com/Azure/k8s-deploy/pull/501) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My41LjQiLCJ1cGRhdGVkSW5WZXIiOiI0My41LjQiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbImFjdGlvbiIsImRlcHMiXX0=--> Reviewed-on: https://gitea.t000-n.de/t.behrendt/k_deploy_workflows/pulls/45 Reviewed-by: t.behrendt <t.behrendt@noreply.localhost> Co-authored-by: Renovate Bot <renovate@t00n.de> Co-committed-by: Renovate Bot <renovate@t00n.de>
Warning
Repo is currently not in use and not tested. We are waiting for proper shared workflow UI support in gitea. Otherwise errors are hard to identify. Follow https://github.com/go-gitea/gitea/issues/24604
Reusable CI Workflow for Kubernetes Services
This directory contains a reusable CI workflow that automatically detects and validates your Kubernetes services, whether they use Helm + Kubernetes or just Kubernetes manifests.
Features
- Automatic Detection: Automatically detects if your service uses Helm (helmfile.yaml) or just Kubernetes manifests
- Conditional Validation: Only runs Helm validation when helmfile.yaml exists
- Flexible Paths: Configurable paths for k8s directory and helmfile
- Comprehensive Validation: Validates both Kubernetes manifests and Helm charts
- CI Summary: Provides a clear summary of what was validated
Usage
Basic Usage (Recommended)
Simply call the workflow without any parameters - it will automatically detect your service type:
jobs:
ci:
uses: ./.gitea/workflows/ci.yaml
Advanced Usage with Custom Paths
If your service uses non-standard directory names:
jobs:
ci:
uses: ./.gitea/workflows/ci.yaml
with:
k8s_dir: "kubernetes/"
helmfile_path: "helm/helmfile.yaml"
Force Skip Helm Validation
If you want to skip Helm validation even when helmfile.yaml exists:
jobs:
ci:
uses: ./.gitea/workflows/ci.yaml
with:
skip_helm_validation: true
Input Parameters
| Parameter | Description | Default | Required |
|---|---|---|---|
k8s_dir |
Path to Kubernetes manifests directory | k8s/ |
No |
helmfile_path |
Path to helmfile.yaml | helmfile.yaml |
No |
skip_helm_validation |
Skip Helm validation even if helmfile exists | false |
No |
Directory Structure Requirements
For Kubernetes-only services:
your-service/
├── k8s/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── ...
└── .gitea/workflows/your-workflow.yaml
For Helm + Kubernetes services:
your-service/
├── k8s/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── ...
├── helmfile.yaml
└── .gitea/workflows/your-workflow.yaml
What Gets Validated
Always (if k8s/ directory exists):
- Kubernetes manifest validation using
kubectl --dry-run - Namespace extraction from repository name
- Basic Kubernetes syntax and schema validation
Conditionally (if helmfile.yaml exists and Helm validation not skipped):
- Helm chart validation using
helmfile diff - Kubernetes manifests in Helm context
- Helm-specific configurations and values
Example Workflows
See example-usage.yaml for complete examples of how to use this workflow in different scenarios.
Available Actions
Extract Chart Name from Repository Name
The extract-chart-name-from-repo-name action extracts the chart name from repository names following the helm-<chart-name> convention.
Usage
- name: Extract chart name
uses: ./.gitea/actions/extract-chart-name-from-repo-name
with:
repo: ${{ github.repository_name }} # e.g., "helm-my-service"
Inputs
| Parameter | Description | Required |
|---|---|---|
repo |
The full repository name (e.g., "helm-my-chart") | Yes |
Outputs
| Output | Description |
|---|---|
chart-name |
The extracted chart name (e.g., "my-chart" from "helm-my-chart") |
Example
For a repository named helm-user-service, this action will extract user-service as the chart name.
Dependencies
This workflow requires:
./.gitea/actions/extract-namespace-from-repo-nameaction./.gitea/actions/extract-chart-name-from-repo-nameactionKUBECONFIGsecret configured in your repository- Access to your Kubernetes cluster
Troubleshooting
Helm validation skipped unexpectedly
- Check if
helmfile.yamlexists in the expected location - Verify the
skip_helm_validationparameter is not set totrue - Ensure the file path is correct if using custom paths
Kubernetes validation skipped
- Verify the
k8s/directory (or custom path) exists - Check the directory contains valid Kubernetes manifests
Permission issues
- Ensure the
KUBECONFIGsecret is properly configured - Verify the workflow has access to your Kubernetes cluster