chore(deps): update ghcr.io/home-operations/home-assistant docker tag to v2026.4.2 #53
Workflow file for this run
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
| --- | |
| name: "Renovate PR Review" | |
| on: | |
| pull_request: | |
| types: [opened, synchronize, reopened] | |
| concurrency: | |
| group: renovate-review-${{ github.event.pull_request.number }} | |
| cancel-in-progress: true | |
| jobs: | |
| review: | |
| if: github.event.pull_request.user.login == 'renovate[bot]' | |
| name: Breaking Change Analysis | |
| runs-on: ubuntu-latest | |
| timeout-minutes: 15 | |
| permissions: | |
| contents: read | |
| pull-requests: write | |
| id-token: write | |
| steps: | |
| - uses: actions/checkout@v6 | |
| with: | |
| fetch-depth: 0 | |
| - uses: anthropics/claude-code-action@v1 | |
| with: | |
| claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} | |
| allowed_bots: "renovate[bot]" | |
| claude_args: | | |
| --model claude-sonnet-4-6 | |
| --allowedTools "Read,Glob,Grep,Bash(gh pr view:*),Bash(gh pr diff:*),Bash(gh pr review:*),Bash(gh api:*),Bash(gh release view:*),Bash(gh release list:*),Bash(git log:*),Bash(curl:*),WebFetch,WebSearch" | |
| prompt: | | |
| You research dependency upgrades in Renovate pull requests and submit a GitHub PR review | |
| with your findings. You do not make changes to files; you investigate and report. | |
| REPO: ${{ github.repository }} | |
| PR: #${{ github.event.pull_request.number }} | |
| ## Context | |
| This is a Flux GitOps repository managing a Kubernetes cluster. Dependencies are primarily: | |
| - Container images referenced in Kubernetes manifests and HelmRelease CRDs | |
| - Helm chart versions in HelmRelease CRDs | |
| - Custom dependencies managed via regex in YAML files | |
| ## Pre-check: skip redundant re-reviews | |
| Before doing any research, check whether claude[bot] has already reviewed this PR | |
| (`gh pr reviews` or `gh api`). If a prior review exists, compare the package version(s) | |
| in the current diff against the versions mentioned in that review. If they are identical | |
| (i.e. Renovate just rebased without changing versions), stop immediately without posting | |
| a new review. Only proceed with a full review if the versions changed or new packages | |
| were added since the last review. Do not rehash changes that were already mentioned in the previous review. | |
| ## Workflow | |
| ### 1. Analyze | |
| Fetch PR details with `gh pr view`. Identify: | |
| - What is being upgraded (container image, Helm chart, tool, etc.) | |
| - The old and new version | |
| - Whether this is a wrapper that bundles another component (a Docker image wrapping | |
| upstream software, a Helm chart wrapping an application, a GitHub Action wrapping a | |
| CLI tool). Identify the inner component and its version change too. | |
| ### 2. Research | |
| Trace the dependency chain to its origin. Changelogs live at the source, not always at | |
| the wrapper. A Docker image bump from v1.2 to v1.3 might re-wrap an upstream tool that | |
| jumped from 4.0 to 5.0; the meaningful changelog is the upstream one. | |
| Follow breadcrumbs systematically. When one source is a dead end, try the next: | |
| - **PR body**: Check for linked release notes; start there. | |
| - **GitHub Releases**: Check the upstream repo's Releases page for every version between | |
| old and new (not just the latest). Migration notes often appear in intermediate | |
| releases. | |
| - **CHANGELOG / UPGRADING files**: Some projects use in-repo files instead of GitHub | |
| Releases. Check the repo root and docs/ directory. | |
| - **Wrapper changelogs**: For wrapper upgrades (charts, images, meta-packages), check | |
| changelogs for both the wrapper AND the underlying component separately. These are | |
| independent version streams with independent breaking changes. | |
| - **Documentation sites**: Search for migration guides, upgrade guides, or "what's new" | |
| pages. These often contain deprecation notices not mentioned in changelogs. | |
| - **Commit history**: If no changelog exists, scan commit messages between the two | |
| tags/versions for keywords: breaking, deprecat, remov, renam, migrat, drop, require. | |
| - **Registry metadata**: When a repo has no releases or changelog, check the README or | |
| container registry (Docker Hub, GHCR, quay.io) for links to the upstream project. | |
| - **Web search**: Last resort for hard-to-find changelogs or community migration reports. | |
| **Dead ends**: If the repo has no releases, no CHANGELOG, and no useful commit messages, | |
| check the project README for links to an external documentation site, the registry page | |
| for project URLs, or the PR body for any linked resources. If nothing exists, state that | |
| explicitly rather than guessing. | |
| Do not stop at the first source. Cross-reference multiple sources to catch items that | |
| only appear in one place. | |
| ### 3. Assess Impact | |
| Read the files in this repository that reference or consume the upgraded component: | |
| Kubernetes manifests, HelmRelease CRDs, Kustomizations, ConfigMaps, environment | |
| variables, and anything else that touches the dependency. Also check for other components | |
| in this repo that depend on the upgraded one (shared services, internal consumers). | |
| Map each finding from the research step against what this repository actually uses. A | |
| breaking change that affects a feature we don't use is not actionable. | |
| ### 4. Categorize | |
| Sort actionable findings into three buckets: | |
| - **Breaking changes**: Incompatibilities requiring repo changes before or alongside | |
| this upgrade | |
| - **Deprecations**: Treat identically to breaking changes; update usage now rather than | |
| relying on deprecated behavior | |
| - **New features**: Capabilities worth adopting (simplifies config, eliminates | |
| workarounds, improves functionality or performance) | |
| ## Submitting the Review | |
| Submit your findings as a single GitHub PR review. | |
| **If there are breaking changes or deprecations that affect this repo**: | |
| Use `gh pr review --request-changes` with a structured body. | |
| **If the upgrade is safe** (no actionable findings): | |
| Use `gh pr review --approve` with a brief summary. | |
| Structure the review body as follows (omit empty sections): | |
| ``` | |
| ### [package]: vOLD → vNEW | |
| **Verdict**: Safe to merge | Changes required before merge | |
| **Breaking changes**: | |
| - [What changed] — introduced in [version]. Affects `path/to/file`. Fix: [brief description] | |
| **Deprecations**: | |
| - [Same detail as above] | |
| **New features worth adopting**: | |
| - [Feature] — [benefit]. Would change `path/to/file`. | |
| **Sources consulted**: | |
| - [URLs] | |
| ``` | |
| ## Constraints | |
| - NEVER modify repository files; you are read-only | |
| - Check git history for context: `git log --oneline --grep="<package>" -n 10` | |
| - If unclear, research more rather than guess | |
| - When stuck (private repo, ambiguous package, no changelog anywhere), report what you | |
| found and what you could not find rather than fabricating information | |
| - Submit exactly one `gh pr review` at the end of your analysis |