fix(ci): cache kubeconform schemas in Validate Manifests job - #2538
Conversation
Sorry, something went wrong.
ksail's kubeconform client fetches JSON schemas from raw.githubusercontent.com on every cold CI run with nowhere to persist them across ephemeral runners. Heavy, repeated traffic across the whole PR queue is what tripped upstream 429 rate-limiting portfolio-wide (2026-07-09), including this repo's own Validate Manifests job. Restore (and re-save) ~/.cache/ksail/kubeconform via actions/cache before the validate step; also corrects the step comment's inaccurate "no network (offline schema cache)" claim now that a real cache exists. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
WalkthroughThis PR updates the GitHub Actions CI workflow to restore and save ksail kubeconform schema cache data under ~/.cache/ksail/kubeconform. It also changes the manifest validation step comment to describe schema fetches as cache-backed. 🚥 Pre-merge checks | ✅ 5 ✅ Passed checks (5 passed)
Comment @coderabbitai help to get the list of available commands. |
Sorry, something went wrong.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agentsVerify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. Inline comments: In @.github/workflows/ci.yaml: - Around line 101-120: The kubeconform schema cache restore step currently relies on the automatic cache save path, so if Validate manifests or Scan manifests fails the updated cache is never persisted and retries may re-fetch schemas. Split the cache handling in the workflow into an explicit actions/cache/restore step and a separate actions/cache/save step, and make the save run with if: always() while skipping exact cache hits so the cache is written back even on job failure.
ℹ️ Review info ⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 56e43087-301a-4cd8-80e5-05bcd91d3e3c
📥 CommitsReviewing files that changed from the base of the PR and between 4331c2f and fb04f75.
📒 Files selected for processing (1)- .github/workflows/ci.yaml
CodeRabbit considers these linked repositories for cross-repo context during reviews:
- devantler-tech/actions (auto-detected) → reviewed against open PR #476 claude/kubeconform-schema-cache instead of the default branch
- devantler-tech/aws (auto-detected)
- devantler-tech/ksail (auto-detected)
- devantler-tech/reusable-workflows (auto-detected)
- devantler-tech/wedding-app (auto-detected)
- devantler-tech/ascoachingogvaner (auto-detected)
- devantler-tech/unifi (auto-detected)
- devantler-tech/provider-upjet-unifi (auto-detected)
- devantler-tech/agent-skills (auto-detected)
Linked repositories findings
devantler-tech/ksail
- pkg/client/kubeconform/client.go:261-279 — kubeconform cache directory is ~/.cache/ksail/kubeconform via os.UserCacheDir(), with fallback to ${TMPDIR}/ksail/kubeconform when user cache dir is unavailable.
- docs/src/content/docs/configuration/workload-validate.mdx:80-88 — docs already describe the local kubeconform cache and note that missing schemas may still be downloaded from remote locations and then cached.
- docs/src/content/docs/cli-flags/workload/workload-validate.mdx:33-45 — CLI docs state schema lookups use a local disk cache and require no network access when cached schemas exist.
devantler-tech/actions
- No direct references found to kubeconform, ksail’s schema cache path, or related schema-download behavior in the inspected refs/pull/476/head checkout.
.github/workflows/ci.yaml (1)109-109: 🔒 Security & Privacy
No issue: actions/cache@5a3ec84eff668545956fd18022155c47e93e2684 already matches v4.2.3.
> Likely an incorrect or invalid review comment.
Sorry, something went wrong.
CodeRabbit: the single actions/cache step only saves on the automatic post-job hook, so a Validate-manifests failure (e.g. the very rate-limit this cache exists to avoid) could skip persisting schemas already fetched that run, leaving every retry to cold-start again. Split into an explicit restore + an if: always() save. 🤖 Generated by the Daily AI Assistant
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1).github/workflows/ci.yaml (1)106-118: 🚀 Performance & Scalability | 🔵 Trivial
Per-run unique cache key means unbounded cache growth over time.
Since key embeds github.run_id, every run creates a brand-new, never-overwritten cache entry (the save's cache-hit != 'true' guard is effectively always true, as the comments already acknowledge). This is a recognized "always-refresh" pattern, but it means repo cache storage grows monotonically and relies entirely on GitHub's LRU eviction to stay under quota — which can cause "cache thrashing, where caches are created and deleted at a high frequency" once the 10GB default is hit. Given this repo already runs many CI jobs, it may be worth monitoring cache usage or scoping the save to only run periodically/on schema-cache-miss rather than every single run, though this isn't a blocker given the small expected schema payload size.
Also applies to: 137-148
🤖 Prompt for AI AgentsVerify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yaml around lines 106 - 118, The kubeconform cache key in the CI workflow is per-run unique because it includes github.run_id, so every execution creates a new cache entry and can cause unbounded cache growth. Update the cache strategy around kubeconform-cache to avoid saving on every run—either make the key less granular, scope the save to periodic/miss-only cases, or otherwise reduce churn—while keeping the restore/save split and the existing cache-hit guard logic in place.
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. Outside diff comments: In @.github/workflows/ci.yaml: - Around line 106-118: The kubeconform cache key in the CI workflow is per-run unique because it includes github.run_id, so every execution creates a new cache entry and can cause unbounded cache growth. Update the cache strategy around kubeconform-cache to avoid saving on every run—either make the key less granular, scope the save to periodic/miss-only cases, or otherwise reduce churn—while keeping the restore/save split and the existing cache-hit guard logic in place.
ℹ️ Review info ⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 956a5fed-6f7f-4e0b-9a4f-e2c1eebca562
📥 CommitsReviewing files that changed from the base of the PR and between fb04f75 and 99704ce.
📒 Files selected for processing (1)- .github/workflows/ci.yaml
CodeRabbit considers these linked repositories for cross-repo context during reviews:
- devantler-tech/actions (auto-detected) → reviewed against open PR #476 claude/kubeconform-schema-cache instead of the default branch
- devantler-tech/aws (auto-detected)
- devantler-tech/ksail (auto-detected)
- devantler-tech/reusable-workflows (auto-detected)
- devantler-tech/wedding-app (auto-detected)
- devantler-tech/ascoachingogvaner (auto-detected)
- devantler-tech/unifi (auto-detected)
- devantler-tech/provider-upjet-unifi (auto-detected)
- devantler-tech/agent-skills (auto-detected)
- GitHub Check: 🧪 Validate Manifests
- GitHub Check: Analyze (python)
- GitHub Check: Analyze (python)
Linked repositories findings
devantler-tech/ksail
- pkg/client/kubeconform/client.go:261-279 — kubeconform cache directory is ~/.cache/ksail/kubeconform via os.UserCacheDir(), with fallback to ${TMPDIR}/ksail/kubeconform when user cache dir is unavailable.
- docs/src/content/docs/configuration/workload-validate.mdx:80-88 — docs already describe the local kubeconform cache and note that missing schemas may still be downloaded from remote locations and then cached.
- docs/src/content/docs/cli-flags/workload/workload-validate.mdx:33-45 — CLI docs state schema lookups use a local disk cache and require no network access when cached schemas exist.
devantler-tech/actions
- No direct references found to kubeconform, ksail’s schema cache path, or related schema-download behavior in the inspected refs/pull/476/head checkout.
.github/workflows/ci.yaml (1)101-148: Restore/save split correctly addresses the prior always-persist gap.
This resolves the earlier feedback: "The recommended and authoritative approach to ensure a cache is saved regardless of job success or failure is to use a separate actions/cache/save step with an always() condition", and the implementation here follows that pattern (explicit restore step id, if: always() && cache-hit != 'true' on save). Key/path/output wiring between the restore and save steps is consistent, and the cached path matches ksail's actual schema cache directory.
Sorry, something went wrong.
CodeRabbit: if: always() also fires while the job is being cancelled, where attempting a cache save is unnecessary and can race the runner teardown. Use !cancelled() instead — still saves on failure, skips on cancellation. 🤖 Generated by the Daily AI Assistant
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1).github/workflows/ci.yaml (1)101-147: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win
Cache key includes github.run_id, so every run always misses and always re-saves.
Lines 116 and the linked comment on Lines 141-142 acknowledge cache-hit is "impossible here since the key includes github.run_id." That means every PR run unconditionally uploads a brand-new cache blob rather than reusing/overwriting a prior one. GitHub Actions caches are capped at 10GB/repo with LRU eviction, so unbounded per-run cache growth accelerates eviction of this cache (and unrelated repo caches), working against the stated goal of avoiding repeated schema fetches/429s across runs.
restore-keys already provides the "fall back to most recent" behavior; the primary key doesn't need run_id for correctness. Consider a stable or coarser-grained key (e.g., drop run_id, or key by date/week) so repeated runs can hit the exact key and skip re-saving, bounding cache churn.
♻️ Suggested key change🤖 Prompt for AI Agents- key: kubeconform-schema-cache-v1-${{ github.run_id }} + key: kubeconform-schema-cache-v1Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yaml around lines 101 - 147, The kubeconform cache key in the CI workflow is using github.run_id, which guarantees a miss on every run and causes unnecessary cache churn. Update the cache key in the kubeconform-cache restore/save steps to a stable or coarser-grained value so the same cache can be reused across runs, while keeping restore-keys for fallback behavior. Keep the existing actions/cache/restore and actions/cache/save flow, but ensure the cache-primary-key can actually hit on повтор runs.
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. Outside diff comments: In @.github/workflows/ci.yaml: - Around line 101-147: The kubeconform cache key in the CI workflow is using github.run_id, which guarantees a miss on every run and causes unnecessary cache churn. Update the cache key in the kubeconform-cache restore/save steps to a stable or coarser-grained value so the same cache can be reused across runs, while keeping restore-keys for fallback behavior. Keep the existing actions/cache/restore and actions/cache/save flow, but ensure the cache-primary-key can actually hit on повтор runs.
ℹ️ Review info ⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 7385c9ac-70f6-4b9b-8197-65ba60358d44
📥 CommitsReviewing files that changed from the base of the PR and between 99704ce and 911ddd1.
📒 Files selected for processing (1)- .github/workflows/ci.yaml
CodeRabbit considers these linked repositories for cross-repo context during reviews:
- devantler-tech/actions (auto-detected) → reviewed against open PR #476 claude/kubeconform-schema-cache instead of the default branch
- devantler-tech/aws (auto-detected)
- devantler-tech/ksail (auto-detected)
- devantler-tech/reusable-workflows (auto-detected)
- devantler-tech/wedding-app (auto-detected)
- devantler-tech/ascoachingogvaner (auto-detected)
- devantler-tech/unifi (auto-detected)
- devantler-tech/provider-upjet-unifi (auto-detected)
- devantler-tech/agent-skills (auto-detected)
- GitHub Check: 🧪 Validate Manifests
- GitHub Check: Analyze (python)
Linked repositories findings
[::devantler-tech/actions::] refs/pull/476/head
- .github/workflows/validate-go-project.yaml:645-758 — the shared Go validation workflow already restores/saves ~/.cache/ksail/kubeconform around go test and go test -race, using the same cache key scheme and !cancelled() save guard. This is the main cross-repo consumer/context for the PR’s CI cache behavior.
- The inline comments explicitly document the intended contract: ksail’s kubeconform client caches schemas under ~/.cache/ksail/kubeconform, and the cache is meant to prevent repeated raw.githubusercontent.com fetches and 429s.
[::devantler-tech/ksail::] current checkout
- pkg/client/kubeconform/client.go:250-275 — ksail writes kubeconform schemas to ~/.cache/ksail/kubeconform (or $TMPDIR/ksail/kubeconform fallback), so the CI cache path matches the runtime cache layout.
- pkg/svc/fluxsubst/fluxsubst.go:396-399 — another ksail component uses the same ksail/kubeconform cache directory, reinforcing that this path is a shared internal contract.
- docs/src/content/docs/cli-flags/workload/workload-validate.mdx:33-45 and docs/src/content/docs/configuration/workload-validate.mdx:80-88 — docs already say schema lookups use a local disk cache and can avoid network access when cached.
[::devantler-tech/reusable-workflows::]
- No direct kubeconform/ksail cache coupling found in the search output; the only hits were unrelated raw.githubusercontent.com guidance in .agents/skills/.../images.md.
.github/workflows/ci.yaml (2)143-143: LGTM! !cancelled() correctly avoids attempting a save during job cancellation while still persisting on validate/scan failure, per the commit intent.
120-136: LGTM!
Also applies to: 149-172
Sorry, something went wrong.
Re: the ⚠️ Outside diff range comments finding on the kubeconform cache key (.github/workflows/ci.yaml restore/save, github.run_id-suffixed primary key) raised across the last two review passes — evaluated, not applying the "drop run_id" suggestion: This is the deliberate GitHub Actions "always-refresh" cache pattern (unique primary key + restore-keys prefix fallback), not an oversight — the in-code comment already flags the trade-off. Switching to a stable key (kubeconform-schema-cache-v1, no run_id) would make the save step's cache-hit != 'true' guard actually skip on every run after the first, since the exact key would then always be found on restore. That would freeze the cache's schema coverage at whatever was fetched on the very first run — any NEW schema kind needed later (e.g. a CRD introduced going forward) would cold-fetch from raw.githubusercontent.com on every subsequent run forever, since there'd be no way to persist an addition to an already-existing immutable cache key. That's a worse outcome than the storage growth this flags, given this is exactly the class of rate-limit failure the PR exists to fix. CodeRabbit's own note calls this "not a blocker given the small expected schema payload size" — agreed; the kubeconform schema catalog subset ksail touches is small (tens of KB–low MB), so LRU eviction pressure on the repo's 10GB cache budget is negligible. Leaving the run_id-keyed design as-is. |
Sorry, something went wrong.
|
🎉 This PR is included in version 1.109.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Sorry, something went wrong.
Why
A portfolio-wide raw.githubusercontent.com 429 rate-limit is currently failing kubeconform schema fetches across ksail and platform CI. This repo's own 🧪 Validate Manifests job (ksail workload validate) is one of the affected checks, hitting the same rate limit on repeated cold fetches.
What
Adds an actions/cache step that persists ~/.cache/ksail/kubeconform — the schema-cache directory the ksail binary already builds internally — across CI runs. Companion fix to devantler-tech/actions#476 (same fix for ksail's own Test/Coverage jobs); this one is independent and stands alone.