Files

.github/renovate-entrypoint.sh

Repository

1 #!/usr/bin/env bash

2 set -euo pipefail

4 # The shared home-operations preset attaches helm-docs as a post-upgrade task

5 # and Renovate's container does not carry it, while `mise run generate-check`

6 # fails on a chart README that was not regenerated. The version is pinned and

7 # Renovate updates it here like any other dependency.

9 # renovate: datasource=github-releases depName=norwoodj/helm-docs

10 HELM_DOCS_VERSION=1.14.2

11 curl -fsSL \

    "https://github.com/norwoodj/helm-docs/releases/download/v${HELM_DOCS_VERSION#v}/helm-docs_${HELM_DOCS_VERSION#v}_Linux_x86_64.tar.gz" \

13 | tar -xz -C /usr/local/bin helm-docs

14 helm-docs --version

16 runuser -u ubuntu renovate

Renovate updates the tool it needs to update the tools

why ·ok L10

The `# renovate:` line above the version is what keeps this file from becoming the one place in the repository that rots. Renovate's own container image is pinned by the action SHA, and the binary it needs is pinned here, so every version in the loop is proposed as an ordinary pull request by the tool whose container it belongs to.

It stays pinned rather than resolving `latest` at run time for the same reason every action carries a SHA: a post-upgrade task that silently changed behaviour between runs would rewrite `charts/koment/README.md` differently on two otherwise identical pull requests, and the diff would be attributed to the dependency being bumped.

The version here and the one in `.mise/config.toml` are separate pins of the same tool - one for the Renovate container, one for a contributor's shell. Renovate bumps both, but nothing forces them to agree, so a chart README regenerated in CI can differ from one regenerated locally if they drift.

2026-08-0501KZ9GB8B3SZDDZ08YK1FBEM7Y