Refresh the action versions the workflows call - #111
Merged
Conversation
Base automatically changed from
2026-09-03--fix-prune-untagged-images-workflow
to
master
September 4, 2026 02:19
GitHub retires the runtime older action releases run on, and actionlint reports each one that has aged out. Four calls were affected: `actions/checkout@v3` in three files, `actions/setup-go@v4`, and `actions/stale@v8`. Move each to the next major, which clears the reports. `actions/stale@v9` matches the pin `stale.yml` already carries, and `actions/checkout@v4` is the version the publish job already calls, so both bring their files in line with what the repository uses elsewhere. Newer majors exist for all three; they are larger jumps with their own behavior changes and are worth taking deliberately rather than alongside a lint fix. With nothing left that trips the rule, `make lint-workflows` no longer excludes it, so an action that ages out is reported on the pull request that would otherwise leave it in place.
indiebrain
force-pushed
the
2026-09-03--refresh-workflow-action-versions
branch
from
September 4, 2026 02:20
84936d8 to
64f0ad3
Compare
rodolfoasantos
approved these changes
Sep 4, 2026
indiebrain
enabled auto-merge (squash)
September 4, 2026 11:32
Merged
indiebrain
added a commit
that referenced
this pull request
Sep 4, 2026
Prepare the repository for release of version v4.6.0. Two files change: `Makefile` sets the version the tag is cut from, and `CHANGELOG.md` moves the `Unreleased` entries under a dated heading. ## Read this before upgrading **A `RedisFailover` that has `auth.secretPath` set restarts once when the operator is upgraded.** Its pod template gains a record of which password it was built for, and that record is new. A failover with no password is unaffected. The Redis pods go together rather than one at a time, because a restarted pod cannot replicate with one that has not restarted yet. Expect a minute or two, a few tens of seconds of it without a master. **This also reaches anyone tracking `latest`.** `docker/metadata-action` runs with the default `flavor.latest=auto`, so a `v*` tag build moves `latest`. Verified on the current release: `latest` and `v4.5.0` share digest `sha256:013e238e59fe…`, and `latest` was written seven seconds after `v4.5.0` in the same run and has not moved since. Publishing v4.6.0 moves `latest` to it. ## This release ships **Five fixes to behavior against a live cluster:** - Removing the `haproxy` block from a `RedisFailover` now removes the Deployment, Service and ConfigMap it created, instead of leaving a proxy routing traffic from a configuration nothing would update again (#107). - A Redis node that could not be inspected no longer counts as "not the master", which could drive recovery into promoting a second master or replacing a healthy one. A failed demotion no longer reports success (#106). - The HAProxy health check authenticates, so `auth.secretPath` is usable at all. Without it every backend stayed `DOWN` and the master endpoint had no backend (#98). - The connected-replicas check authenticates, so the operator stops killing a healthy master's replica connections on every reconcile under `requirepass` (#102). - A password change on a running `RedisFailover` is applied rather than leaving Redis on the password it started with and the operator locked out (#104). **Supply chain and image:** - Built with Go 1.25.14 with `golang.org/x/net` at v0.58.0, taking the reachable vulnerability count to zero, and the base images pinned by digest (#108). - The image carries a Software Bill of Materials, and provenance moves to `max` (#109). - Published to `ghcr.io/powerhome` alongside Docker Hub (#93). ## What this does to the open issues Referenced, not closed. Closing is left to a person once the claims are true of a published artifact. | Issue | State after this release | | --- | --- | | #99 (connected-replica check omits password) | Fixed by #102. | | #101 (v4.5.0 image has fixable vulnerabilities) | Fixed by #108. The issue reports against `v4.5.0`, which predates the fix, so it is only true of an artifact once v4.6.0 is published. | | #100 (no-quorum recovery can promote wrongly) | **Partially** addressed by #106. `SetOldestAsMaster` still sorts candidates by pod `CreationTimestamp` (`operator/redisfailover/service/heal.go:115`), which #100's acceptance criteria rule out directly. No integration coverage was added either: #106 records that the harness cannot induce the selective inspection failure the issue's reproduction turns on. Do not close it. | ## Changelog style The entries collected for this release had grown to multi-paragraph bodies running 88 lines. Every release entry from v4.5.0 back is a single line naming the change and linking its pull request, in blocks of five to eight lines. These are reduced to one line each to match. The reasoning lives in the linked pull requests, and the long form goes into the v4.6.0 GitHub Release body, which is what line 8 of the changelog already points readers to. The one thing a reader must not miss, the restart above, is kept in the file as an upgrade note above the entries. ## A correction to the changelog The changelog carried `## [v4.5.1] - 2026-08-18`. **No such release exists**: no `v4.5.1` git tag, and no `v4.5.1` image on Docker Hub or in the ghcr package. The heading was added by feature pull request #93 rather than by a release commit, and it is dated three days before #93 merged. The heading is removed. This file lists releases, and a heading for a version with no tag, no image and no release notes points a reader at something they cannot go and get. The record that the claim was retracted belongs in this repository's history, which carries it, rather than in the file. The change it listed ships here. ## Not included Workflow and continuous-integration changes (#95, #96, #110, #111, #112, #113, #114) are left out, along with the `/etc/cni/net.d` setup-minikube workaround that rode in on #93. They change no published artifact and no operator behavior, and the GitHub Release auto-notes list every merged pull request anyway. ## After this merges Capture the squash commit rather than tagging `HEAD` — this repository squash-merges, so the commit to tag does not exist until the merge and is not the branch head: ``` sha=$(gh pr view 115 --json mergeCommit -q .mergeCommit.oid) git fetch origin --tags git show $sha:Makefile | head -1 # must read VERSION := v4.6.0 git tag -a v4.6.0 -m "v4.6.0" "$sha" git push origin v4.6.0 ``` Then, once the tag build is green: ``` gh release create v4.6.0 --title v4.6.0 --notes-file <the long-form notes> ``` Order matters: `gh release create` against a tag that does not exist yet creates one from the default branch, which tags the wrong commit and fires another build. If the tag build fails, re-run the failed jobs. Do not delete and re-push the tag: re-running is idempotent since the bases are digest-pinned, while a deleted public `v*` tag also drops out of the image prune workflow's `exclude-tags: 'v*'` protection. ## Verification - `## Unreleased` is retained and empty, matching how v4.5.0, v4.4.1 and v4.4.0 were cut. - The v4.6.0 block is 24 lines against 5 to 8 for its neighbours, with one `### Added`, one `### Changed`, one `### Fixed`. The previous `Unreleased` section had two `Added` and two `Fixed` sections interleaved. - This will be the first semantic version image published to `ghcr.io`, so the first real exercise of `exclude-tags: 'v*'` in the prune workflow. Dry-run that workflow afterwards and confirm `v4.6.0` appears in no deletion list. - It is also the first tag build to carry a bill of materials, since #109 landed after v4.5.0. Worth confirming rather than assuming: `docker buildx imagetools inspect powerhome/redis-operator:v4.6.0 --format '{{ json .SBOM }}'`
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
2 participants
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.
What
GitHub retires the runtime that older action releases run on, and
actionlintreports each call that has aged out. There were four:ci.yaml(3 jobs)actions/checkout@v3actions/checkout@v4ci.yaml(3 jobs)actions/setup-go@v4actions/setup-go@v5helm.ymlactions/checkout@v3actions/checkout@v4staleissues.yamlactions/stale@v8actions/stale@v9With nothing left that trips the rule,
make lint-workflowsdrops the-ignoreflag it carried, so an action that ages out from here on is reported on the pull request that would otherwise leave it in place.Why the next major and not the newest
actions/checkoutis at v7,actions/setup-goat v7, andactions/staleat v11. The next major clears the reports with the smallest behavior change, and in two cases it matches what the repository already does:actions/checkout@v4is the version the publish job inci.yamlalready calls, so this makes the file internally consistent.actions/stale@v9is the versionstale.ymlalready pins by digest, and that file is managed bypowerhome/software, so v9 is the version this organization has settled on.Jumping several majors changes defaults (caching behavior in
setup-go, and the stale bot's own defaults, which act on real issues and pull requests on a schedule). That is worth doing deliberately, on its own, rather than riding along with a lint fix.Verification
actionlintreports nothing across all five workflow files with no rule excluded:Every input used at each call site is still valid at the new version.
staleissues.yamlkeeps its full set (days-before-issue-stale,days-before-issue-close,stale-issue-label, the two messages,days-before-pr-stale,days-before-pr-close,repo-token), andsetup-gokeepsgo-version-fileandcache.