chore(deps): Update testing-tools - abandoned#10
Open
github-actions[bot] wants to merge 9 commits into
Open
Conversation
Introduces a self-hosted Renovate runner that shadows dependabot during a soft-launch phase. Renovate replaces and extends dependabot's coverage by also tracking the tool versions pinned in .settings.yaml (the project's single source of truth) — something dependabot cannot do. Coverage delta over dependabot: gomod, github-actions, dockerfile, and terraform are all preserved (with the kubernetes/golang-x/opencontainers gomod groups carried forward verbatim). New: npm (site/), helm-values (partial), the .settings.yaml tool set via a custom regex manager (28 annotated entries), and an automated chainsaw-checksum refresh hook. Key design decisions: - Self-hosted via renovatebot/github-action with the built-in GITHUB_TOKEN. The repo's /ok reviewer-comment policy re-fires CI on bot PRs, sidestepping GitHub's "GITHUB_TOKEN cannot trigger workflows" limitation. No PAT or App needed. - The `configurationFile:` action input is intentionally NOT passed: passing it would load .github/renovate.json5 as both the global config AND the auto-discovered repo config, doubling every customManager and duplicating PRs. - .settings.yaml entries are grouped by top-level YAML section via `depType=<section>` annotations + matchDepTypes packageRules. Branches read cleanly: `renovate/build-tools`, `renovate/test-images`, `renovate/major-site`, etc. - nvkind (pinned by main-branch SHA) gets a dedicated git-refs digest customManager with a distinct `# renovate-digest:` annotation prefix so the broad regex doesn't double-extract it. - Auto-merge is positive-listed (build/lint/security tooling, plus github-actions/gomod/npm patches). Cluster-impacting pins (helm, kubectl, kind, kwok, chainsaw, karpenter, gpu-operator, kindest/node, CUDA, Go toolchain, node, hugo, nvkind) require human review on every bump, even patches. - Schedule is `before 6am every weekday` since self-hosted Renovate cannot consume GitHub vulnerability alerts (Mend-only); weekday cadence narrows the CVE-to-PR window. - Both image references (Makefile validator + workflow runner) are digest-pinned to `sha256:00185c0d...` for supply-chain consistency with the project's GitHub Actions pinning policy. Verified end-to-end: - make lint-renovate validates against ghcr.io/renovatebot/renovate:43 cleanly. - merge-gate.yaml gains a path-filtered verify-renovate job that runs the same validator only when .github/renovate.json5 changes. - Local docker dry-run with the live config produces 6 distinct PR branches (down from 10 ungrouped) covering vue/vite/mermaid/esbuild bundled in renovate/site, kindest/node + cuda bundled in renovate/test-images, and 3 majors split into renovate/major-* for isolated review. - The chainsaw post-upgrade hook is wired and idempotent: rerun against the currently-pinned v0.2.14 produces zero diff. Soft-launch plan in .github/RENOVATE.md (Phases A-E). dependabot.yml and dependabot-auto-merge.yaml remain in place until Phase D confirms Renovate is healthy; Phase E is a follow-up PR removing them.
* fix(ci): make workflow cron the single Renovate schedule The previous setup had two scheduling layers that didn't overlap: the workflow cron fired Mondays at 09:00 UTC, while renovate.json5's `schedule: ["before 6am every weekday"]` only created PRs before 06:00 UTC. Every cron-triggered run landed three hours after the window closed and Renovate held all PRs in "Awaiting Schedule" — including the manually-dispatched runs we used during the soft-launch exercise. For self-hosted Renovate, the config-side `schedule:` field is redundant: Renovate only runs when the workflow fires, so the workflow cron already controls cadence. Removing the second layer: - Eliminates the alignment trap (the failure mode is silent — runs "succeed" while creating zero PRs). - Makes `workflow_dispatch` actually useful — manual triggers now create PRs immediately, regardless of clock time. - Removes the dependency on Dependency-Dashboard checkbox ticking to bypass the schedule for ad-hoc runs. Cron moved from `0 9 * * 1` (Mon 09:00) to `0 5 * * 1-5` (Mon-Fri 05:00) so PRs land before standup. RENOVATE.md updated to document the single-source-of-truth design and call out the rationale. * fix(ci): add release cooldown to renovate config Adds `minimumReleaseAge: "3 days"` globally and raises it to 7 days for the two auto-merge rules. Defends against malicious-publish ratchet attacks where a poisoned version goes live for hours then gets yanked (event-stream, colors.js, node-ipc, etc.). Trade-off: legitimate CVE patches land 3 days later than they would otherwise; for a project whose security-relevant deps come entirely from upstream tooling we don't write ourselves, the marginal protection is worth it. `internalChecksFilter: "strict"` excludes too-young releases rather than parking them in the Dependency Dashboard as "pending", keeping the dashboard signal clean — it shows what's about to land, not what's blocked behind cooldown. Auto-merge rules carry the higher 7-day cooldown because those updates skip human review; the cooldown is the only defense layer left if an attacker pushes a malicious patch.
…te) (#4) * fix(ci): merge anchore + sigstore into single supply-chain group Both Anchore (grype/syft/sbom-action/scan-action) and Sigstore (cosign/ cosign-installer) are supply-chain hardening tools. Their bumps tend to be reviewed by the same eyes for the same reasons. Bundling them into a single `supply-chain` group reduces 2 PRs/cycle to 1 without coupling unrelated tooling. The cross-manager behavior is preserved — the matchPackageNames glob still picks up both .settings.yaml entries (via the regex manager: anchore/grype, anchore/syft, sigstore/cosign) and GitHub Actions entries (anchore/sbom-action, anchore/scan-action, sigstore/cosign-installer). Branch slug becomes `renovate/supply-chain`. * fix(ci): merge docs-tools + site into single docs group The docs build chain has two halves: hugo (.settings.yaml docs_tools, used by .github/actions/build-versioned-site for versioned landing pages) and site/package.json (vitepress + vue + mermaid + esbuild + vite, the main docs site). They're parts of one pipeline; reviewing their bumps together is the natural workflow. Both packageRules now share `groupName: "docs"` — Renovate uses the group slug to determine the branch, so deps from either manager (custom.regex on .settings.yaml + npm on site/package.json) land in the single `renovate/docs` PR. Major bumps still split into `renovate/major-docs` per Renovate's default behavior.
The `actions/checkout` step was modeled on NVIDIA/gpu-operator's renovate workflow, but our setup deliberately does not pass `configurationFile:` (to avoid customManager doubling — see PR #3). Without that input, the renovatebot/github-action clones the repo itself inside Docker and has no need for an outer working tree. Observed failure: every Renovate run since the practice exercise started would create the first eligible branch (e.g. `renovate/build-tools`) and then abort 0.3s later with "Repository has changed during renovation" — even though no commit to main happened during the run window. The credentials and working tree planted at /home/runner/work by `actions/checkout` are the suspect: Renovate's container-internal git operations and the runner-side git state cross-contaminate, and Renovate misinterprets its own branch push as a base-branch advance. Removing the step removes the cross-contamination surface. The action documents that checkout is not required when using its default internal-clone mode.
…kflow (#6) Reverts toward the known-working NVIDIA/gpu-operator pattern after PRs #5 (drop checkout) and earlier failed to clear the persistent "Repository has changed during renovation" abort. Three concrete changes: 1. **Add back actions/checkout.** The action documents that it clones internally, but the host-side git state planted by checkout appears to keep Renovate's pre/post hooks consistent. Removing it in PR #5 did not fix the abort, suggesting checkout was never the culprit. 2. **Pass configurationFile: .github/renovate.json5.** The earlier concern about customManager doubling came from `RENOVATE_PLATFORM=local` dry-runs; in production (platform=github) Renovate dedupes by manager identity, so the same-file case is benign. Without configurationFile, the action runs Renovate without a global config — and that mode is associated with mid-run race conditions that surface as "repository-changed" aborts right after a successful branch push. 3. **Set RENOVATE_DRY_RUN conditionally.** Previously the env var was emitted on every run as `''` (empty string when dryRun=false). Renovate's option parser may treat the *presence* of the env var differently from its unset state. The new "Configure dry-run mode" step writes the var to GITHUB_ENV only when explicitly requested, keeping the env clean for the common case. Verified end-to-end via actionlint. Soft-launch loop continues — once this lands, dispatch Renovate manually and check whether `renovate/build-tools` (the only bundle past the cooldown filter) finally produces a PR alongside its branch.
#7) Root cause of the persistent "Repository has changed during renovation" aborts since PR #4 — Renovate was calling POST /repos/{owner}/{repo}/ statuses/{sha} after each branch creation to write a stability status check (tied to the cooldown / merge-confidence flow). The workflow's permissions block had contents:write, pull-requests:write, issues:write but not statuses:write, so the call 403'd with "integration- unauthorized". Renovate's error handler maps that internally to "repository-changed", which is why every prior debugging attempt (checkout, configurationFile, dry-run env, digest pin) chased the wrong symptom. Confirmed via debug log on run 25346172853: Request failed with status code 403 (Forbidden): POST .../statuses/cf3dc7d1... "x-accepted-github-permissions": "statuses=write" DEBUG: Caught error setting branch status - aborting Error: integration-unauthorized DEBUG: Passing repository-changed error up The earlier hypothesis fixes in PRs #5 and #6 weren't wrong per se (actions/checkout and configurationFile aren't the cause, and RENOVATE_DRY_RUN='' isn't either) — they just couldn't have fixed the underlying permission gap. With statuses:write added, Renovate's post-branch status-check call should succeed and the run should complete normally.
Confirmed in production run 25346453345: the regex manager stats
showed `"regex": {"fileCount": 4, "depCount": 56}` instead of the
expected 2/28. With `configurationFile: .github/renovate.json5`
passed, the action mounts the file as Renovate's global config AND
Renovate auto-discovers the same file from the cloned working tree;
both loads register the customManagers and every annotation gets
extracted twice. The doubling produced 14 "Cannot find replaceString
in current file content. Was it already updated?" warnings across
the four created branches — Renovate's first pass applied the
replacement, the second pass tried to re-apply but the content no
longer matched.
PR #6 added `configurationFile:` chasing the "repository-changed"
aborts under the wrong hypothesis; PR #7 found and fixed the actual
cause (missing `statuses: write` permission). With #7 in place we
can drop `configurationFile:` cleanly. Earlier dry-run experiments in
RENOVATE_PLATFORM=local mode had already shown this doubling, but I
mis-attributed it to local-mode specifics. Production confirms the
behavior is the same.
`actions/checkout` stays — it's not the cause of any issue we've
seen, and the upstream gpu-operator pattern keeps it.
github-actions
Bot
force-pushed
the
renovate/testing-tools
branch
from
86e4dcf to
c2ffad0
Compare
After the first successful production Renovate run on the practice fork created PRs #8–#11, the next 8 eligible bundles all landed in the dashboard's Rate-Limited section instead of as PRs: - renovate/github-actions, linting, python-3.x, supply-chain - renovate/major-linting, major-docs, major-github-actions, major-test-images Reason: prHourlyLimit was 4 and we'd already created 4 in the run. Renovate's hourly cap is a per-repo rolling-window throttle whose default (2) is tuned for Mend's hosted service serving many repos against the same upstream registries — for our self-hosted single repo, the constraint is purely "don't flood reviewers", which is already what prConcurrentLimit handles. Setting prHourlyLimit to 10 (matching prConcurrentLimit) means the hourly cap never holds back updates that the concurrent-PR cap would otherwise allow through. With cooldown filtering (3 days global, 7 days for auto-merge) plus group consolidation already in place, even a backlog-clearing run will rarely produce more than 10 PRs at once. Patch auto-merge drains the safe ones without human attention.
github-actions
Bot
force-pushed
the
renovate/testing-tools
branch
from
c2ffad0 to
73de49a
Compare
Author
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
github-actions
Bot
changed the title
Author
Autoclosing SkippedThis PR has been flagged for autoclosing. However, it is being skipped due to the branch being already modified. Please close/delete it manually or report a bug if you think this is in error. |
njhensley
added a commit
that referenced
this pull request
May 13, 2026
Audit findings #2, #3, #4 against generated evidence bundles: predicate.validatorImages was always null, predicate.validatorCatalogVersion was always empty, and the pointer's signer block emitted zero-valued identity/issuer + rekorLogIndex:0 for unsigned bundles — making a real Rekor log index 0 indistinguishable from 'no Rekor entry' and an unsigned bundle indistinguishable from one whose signer fields failed to extract. Changes: - emitRecipeEvidence loads the validator catalog once and feeds it to both the BOM (chart refs + validator images) and the predicate's ValidatorCatalogVersion + ValidatorImages fields. Shared dedupValidatorImages helper collapses the catalog's one-entry-per-check duplication (deployment/perf/conformance all share images). - PointerAttestation.Signer becomes *PointerSigner, omitempty. Unsigned bundles emit the attestation entry with no signer block at all; signed bundles always carry non-nil Signer with populated Identity and Issuer. - PointerSigner.RekorLogIndex becomes *int64, omitempty. nil = no Rekor entry created (--no-rekor signing path); non-nil = real Rekor log index, even when zero (Rekor's first-ever entry occupies index 0 and that's a legitimate position a consumer should be able to verify). - signAndPushBundle's no-push path returns signPushOutcome{} rather than signPushOutcome{Sign: &SignResult{}}, matching its existing 'All fields are nil when --push is absent' comment and letting buildPointerInputs do the right nil-check. Test coverage: - pkg/evidence/attestation/pointer_test.go: unsigned bundles MUST omit the signer YAML block; signed-without-rekor bundles MUST omit rekorLogIndex. Both assertions check rendered YAML, not just the struct. - pkg/cli/validate_evidence_test.go (new): catalogVersion, dedupValidatorImages, validatorImagesForPredicate helpers; and buildPointerInputs covers the three outcome shapes (unsigned, signed-with-rekor, signed-without-rekor). Notes: - ValidatorImages.Digest remains blank in this PR. The catalog records image refs by tag, not by digest; resolving each ref to a digest needs a registry round-trip per image, which validate's hot path avoids. Audit item #10 (BOM image digests) tracks the longer-term resolver path; the same resolver will populate this field when it lands.
njhensley
added a commit
that referenced
this pull request
May 13, 2026
Audit findings #2, #3, #4 against generated evidence bundles: predicate.validatorImages was always null, predicate.validatorCatalogVersion was always empty, and the pointer's signer block emitted zero-valued identity/issuer + rekorLogIndex:0 for unsigned bundles — making a real Rekor log index 0 indistinguishable from 'no Rekor entry' and an unsigned bundle indistinguishable from one whose signer fields failed to extract. Changes: - emitRecipeEvidence loads the validator catalog once and feeds it to both the BOM (chart refs + validator images) and the predicate's ValidatorCatalogVersion + ValidatorImages fields. Shared dedupValidatorImages helper collapses the catalog's one-entry-per-check duplication (deployment/perf/conformance all share images). - PointerAttestation.Signer becomes *PointerSigner, omitempty. Unsigned bundles emit the attestation entry with no signer block at all; signed bundles always carry non-nil Signer with populated Identity and Issuer. - PointerSigner.RekorLogIndex becomes *int64, omitempty. nil = no Rekor entry created (--no-rekor signing path); non-nil = real Rekor log index, even when zero (Rekor's first-ever entry occupies index 0 and that's a legitimate position a consumer should be able to verify). - signAndPushBundle's no-push path returns signPushOutcome{} rather than signPushOutcome{Sign: &SignResult{}}, matching its existing 'All fields are nil when --push is absent' comment and letting buildPointerInputs do the right nil-check. Test coverage: - pkg/evidence/attestation/pointer_test.go: unsigned bundles MUST omit the signer YAML block; signed-without-rekor bundles MUST omit rekorLogIndex. Both assertions check rendered YAML, not just the struct. - pkg/cli/validate_evidence_test.go (new): catalogVersion, dedupValidatorImages, validatorImagesForPredicate helpers; and buildPointerInputs covers the three outcome shapes (unsigned, signed-with-rekor, signed-without-rekor). Notes: - ValidatorImages.Digest remains blank in this PR. The catalog records image refs by tag, not by digest; resolving each ref to a digest needs a registry round-trip per image, which validate's hot path avoids. Audit item #10 (BOM image digests) tracks the longer-term resolver path; the same resolver will populate this field when it lands.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v4.1.1→v4.1.4v1.8.0→v1.12.0v1.35.0→v1.36.0v4.52.4→v4.53.278a0a51→56db9be0.9.0→0.9.30.37.0→0.37.3Release Notes
helm/helm (helm/helm)
v4.1.4: Helm v4.1.4Compare Source
Helm v4.1.4 is a security fix patch release. Users are encouraged to upgrade for the best experience.
The community keeps growing, and we'd love to see you there!
Security fixes
Chart.yamlname dot-segment.provis missing, allowing unsigned plugin installA big thank you to the reporters of these issues (@maru1009, @1seal).
Installation and Upgrading
Download Helm v4.1.4. The common platform binaries are here:
The Quickstart Guide will get you going from there. For upgrade instructions or detailed installation notes, check the install guide. You can also use a script to install on any system with
bash.What's Next
Changelog
05fa379(George Jenkins)4e7994d(George Jenkins)2581943(George Jenkins)36c8539(George Jenkins)c61e086(Terry Howe)v4.1.3: Helm v4.1.3Compare Source
Helm v4.1.3 is a patch release. Users are encouraged to upgrade for the best experience.
Note there was no 4.1.2 release due to a release automation issue.
The community keeps growing, and we'd love to see you there!
Notable Changes
FailedStatusis treated as a terminal state, causing upgrades to fail prematurely when cluster autoscalers needed time to provision nodes, or when pods were being deleted during rolling updates #31897--atomicflag on install command #31901Installation and Upgrading
Download Helm v4.1.3. The common platform binaries are here:
BlobNotFoundThe specified blob does not exist.RequestId:a97d6fdb-301e-0045-72a5-b120d7000000
Time:2026-03-11T22:20:16.6057319Z)
This release was signed with
208D D36E D5BB 3745 A167 43A4 C7C6 FBB5 B91C 1155and can be found at @scottrigby keybase account. Please use the attached signatures for verifying this release usinggpg.The Quickstart Guide will get you going from there. For upgrade instructions or detailed installation notes, check the install guide. You can also use a script to install on any system with
bash.What's Next
Changelog
c94d381(Matheus Pimenta)b36d660(Austin Abro)04a91af(Austin Abro)c3c57db(Evans Mungai)d47cb2b(Evans Mungai)790bf92(Evans Mungai)f7cec12(Evans Mungai)d94a5c9(Evans Mungai)8c5fe4e(Evans Mungai)217db28(dependabot[bot])7cb43e0(Travis Leeden)5b26d4f(Terry Howe)360c131(Terry Howe)69a0a92(dependabot[bot])b868e6a(Matheus Pimenta)dbfbea9(rohansood10)099192c(dependabot[bot])4967ead(Pedro Tôrres)2fe6b10(Pedro Tôrres)e3e2d01(Evans Mungai)c15e711(Manuel Alonso)df82e68(Manuel Alonso)4b896ca(Manuel Alonso)3fc7939(Manuel Alonso Gonzalez)6017d2b(Manuel Alonso)f451967(Manuel Alonso)fdadff5(Manuel Alonso)10d6067(Manuel Alonso)0fec40f(Mujib Ahasan)2637498(Mujib Ahasan)961d7d7(Mujib Ahasan)29e4506(Mujib Ahasan)d55b0b9(Mujib Ahasan)c1c090e(Mujib Ahasan)5e09313(Mujib Ahasan)f289d16(Mujib Ahasan)bfac739(Orgad Shaneh)kubernetes-sigs/karpenter (kubernetes-sigs/karpenter)
v1.12.0Compare Source
Features
Bug Fixes
Documentation
Tests
Chores
v1.11.1Compare Source
Bug Fixes
v1.11.0Compare Source
Features
Bug Fixes
Documentation
Tests
v1.10.0Compare Source
Features
Bug Fixes
Documentation
Tests
Chores
v1.9.0Compare Source
Features
Bug Fixes
Documentation
Code Refactoring
Tests
Continuous Integration
Chores
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate.