CI/CD Automation and Renovate

Relevant source files

• .github/workflows/flux-local.yaml
• .github/workflows/fly-deploy.yaml
• .github/workflows/image-pull.yaml
• .github/workflows/label-sync.yaml
• .github/workflows/labeler.yaml
• .github/workflows/renovate.yaml
• .github/workflows/tag.yaml
• .github/workflows/terraform-publish.yaml
• kubernetes/apps/actions-runner-system/actions-runner-controller/app/helmrelease.yaml
• kubernetes/apps/actions-runner-system/actions-runner-controller/ks.yaml
• kubernetes/apps/actions-runner-system/actions-runner-controller/runners/home-ops/helmrelease.yaml
• kubernetes/apps/ai/toolhive/config/externalsecret.yaml
• kubernetes/apps/cert-manager/cert-manager/ks.yaml
• kubernetes/apps/kube-system/coredns/ks.yaml
• kubernetes/apps/renovate/kustomization.yaml
• kubernetes/apps/renovate/renovate-operator/app/helmrelease.yaml
• kubernetes/apps/renovate/renovate-operator/app/kustomization.yaml
• kubernetes/apps/renovate/renovate-operator/app/ocirepository.yaml
• kubernetes/apps/renovate/renovate-operator/jobs/externalsecret.yaml
• kubernetes/apps/renovate/renovate-operator/jobs/job.yaml
• kubernetes/apps/renovate/renovate-operator/jobs/kustomization.yaml
• kubernetes/apps/renovate/renovate-operator/ks.yaml

This section covers the automation pipelines that maintain the home-ops repository. The CI/CD architecture relies on GitHub Actions for external validation and artifact publishing, and a self-hosted actions-runner-controller within the cluster for tasks requiring direct hardware or node access.

Renovate Dependency Automation

The repository utilizes Renovate to maintain up-to-date dependencies across Helm charts, container images, and Terraform providers. This is implemented through two complementary mechanisms: a GitHub Actions workflow for repository-level updates and an in-cluster RenovateJob for continuous background maintenance.

GitHub Actions Workflow

The Renovate workflow runs on an hourly schedule or can be triggered manually via workflow_dispatch.github/workflows/renovate.yaml11-13 It uses a GitHub App token generated via actions/create-github-app-token to bypass standard GITHUB_TOKEN rate limits and allow Renovate to trigger further CI runs on its PRs .github/workflows/renovate.yaml47-53

In-Cluster Renovate Operator

For continuous reconciliation, the renovate-operator is deployed in the renovate namespace kubernetes/apps/renovate/renovate-operator/ks.yaml A RenovateJob CRD defines the execution parameters, including a Redis cache backed by dragonfly.database.svc.cluster.local to speed up dependency lookups kubernetes/apps/renovate/renovate-operator/jobs/job.yaml19-20

Dependency Data Flow

The following diagram illustrates how Renovate identifies and updates dependencies.

Renovate Automation Logic

[Flowchart Diagram]

Sources: .github/workflows/renovate.yaml11-73kubernetes/apps/renovate/renovate-operator/jobs/job.yaml1-31

Pull Request Validation and flux-local

To ensure that changes to the kubernetes/ directory do not break the cluster, the Flux Local workflow performs static analysis and diff generation on every Pull Request .github/workflows/flux-local.yaml4-6

1. Filter: The workflow uses bjw-s-labs/action-changed-files to detect changes specifically within the kubernetes/ path .github/workflows/flux-local.yaml22-26
2. Test: It executes flux-local test to validate the Kustomize build and Helm template output for all namespaces .github/workflows/flux-local.yaml39-47
3. Diff: It runs flux-local diff for both HelmRelease and Kustomization resources .github/workflows/flux-local.yaml58-59 This compares the PR branch against the main branch and posts the resulting diff as a sticky comment on the PR .github/workflows/flux-local.yaml122-130

Sources: .github/workflows/flux-local.yaml1-145

Image Pre-Pulling via talosctl

When a Pull Request updates a container image, the Image Pull workflow proactively pulls the new image onto the Talos nodes before the PR is merged. This minimizes downtime by ensuring the image is already present in the node’s internal cache when Flux eventually reconciles the change.

• Extraction: The workflow uses flux-local get cluster --only-images to extract the list of images from both the default branch and the PR branch .github/workflows/image-pull.yaml47-57
• Diffing: It identifies new images by subtracting the default list from the PR list using jq.github/workflows/image-pull.yaml79-85
• Execution: The pull operation runs on a self-hosted runner (home-ops-runner) .github/workflows/image-pull.yaml96 It uses talosctl image pull to inject the image directly into the Talos nodes .github/workflows/image-pull.yaml109

Sources: .github/workflows/image-pull.yaml1-124kubernetes/apps/actions-runner-system/actions-runner-controller/runners/home-ops/helmrelease.yaml55-68

Infrastructure and Artifact Publishing

Terraform OCI Artifacts

The Publish Terraform workflow packages the infrastructure/terraform directory into an OCI artifact and pushes it to GitHub Container Registry (GHCR) .github/workflows/terraform-publish.yaml3-9

• It uses the flux push artifact command to create the OCI image .github/workflows/terraform-publish.yaml44-47
• The artifact is tagged with the short git commit SHA and the main tag .github/workflows/terraform-publish.yaml39-51
• This allows the in-cluster tofu-controller to consume Terraform modules as OCI sources.

Fly.io Deployment

Workflows in infrastructure/flyio/ (Gatus and Vaultwarden) are deployed via the Deploy to Fly workflow .github/workflows/fly-deploy.yaml1-17

• It uses dorny/paths-filter to detect which specific application (Vaultwarden or Gatus) changed .github/workflows/fly-deploy.yaml42-50
• Deployment is executed using flyctl deploy --remote-only.github/workflows/fly-deploy.yaml110

Sources: .github/workflows/terraform-publish.yaml1-52.github/workflows/fly-deploy.yaml1-118

Repository Maintenance Workflows

Workflow	Schedule / Trigger	Purpose
Tag	0 0 1 * * (Monthly)	Generates a CalVer tag (e.g., 2024.5.0) based on the current date and increments the patch version if a tag for that month already exists .github/workflows/tag.yaml8-47
Labeler	PR to main	Automatically applies labels to PRs based on the paths of the files changed, using the configuration in .github/labeler.yaml.github/workflows/labeler.yaml7-33
Label Sync	0 0 * * * (Daily)	Synchronizes GitHub labels with the definitions in .github/labels.yaml, ensuring consistent naming and coloring across the repo .github/workflows/label-sync.yaml11-34

Self-Hosted Runner Architecture

The home-ops-runner is a gha-runner-scale-set deployed via the actions-runner-controllerkubernetes/apps/actions-runner-system/actions-runner-controller/runners/home-ops/helmrelease.yaml19

Runner Implementation Detail

[Flowchart Diagram]

The runner pod is configured with a volume mount for talos.dev secrets, which provides the talosconfig required for the Image Pull workflow to communicate with the node’s API kubernetes/apps/actions-runner-system/actions-runner-controller/runners/home-ops/helmrelease.yaml65-73 It also captures the host IP in the NODE environment variable to target the specific node for image operations kubernetes/apps/actions-runner-system/actions-runner-controller/runners/home-ops/helmrelease.yaml61-64

Sources: kubernetes/apps/actions-runner-system/actions-runner-controller/runners/home-ops/helmrelease.yaml1-74kubernetes/apps/actions-runner-system/actions-runner-controller/app/helmrelease.yaml19-36