Tags give the ability to mark specific points in history as being important
-
-
-
v0.10.2
Release: v0.10.2ca8d5ce2 · ·v0.10.2 — integration-key deletion stops trusting a partial render The circuit breaker on integration-key deletion withheld only when spec.integrationKeys[] was entirely empty. Its own reasoning -- that a service dropping every key at once is more likely a broken render than a teardown -- applies equally to a service dropping most of them, and a truncated overlay leaving one key of six standing deleted the other five. A GoAlert key ID is the customer's webhook bearer token and cannot be reissued. Neither obvious fix works. Counting keys blocks adoption cleanup, where a service legitimately declares one key while GoAlert holds several that were never in spec. Keying off history blocks the feature itself, since 'these keys were in spec last generation' describes deliberate declarative removal exactly. So the removal set is split by whether the operator has ever managed each key, which status.integrationKeys already records. Keys it never managed are adoption cleanup and are deleted at any size. Keys that were in spec and just left are withheld when they cover more than half of what was being managed. Removing one key from a six-key service still works. Verified against a live GoAlert instance, not only the mock: six keys to one keeps all six; five keys created directly in GoAlert are all removed while the declared one survives; and a spec going from {a,b,c} to {c,d} in a single apply withholds a and b while still creating d. Two limits are documented rather than implied. Dropping one key of two is indistinguishable from meaning it. And the protection depends on status.integrationKeys surviving, so a CR recreated with empty status treats every pre-existing key as unmanaged. Also in this release: CI now refuses to publish a release whose chart appVersion does not match its tag, an upgrade-verification recipe that queries GoAlert rather than trusting operator status, and a race-free test suite -- 27 data races had been latent since v0.7.0 -- with the detector running on every pipeline. No CRD schema change from v0.10.1. -
v0.10.1
Release: v0.10.1ab3a96ba · ·v0.10.1 — schedule cold-cache grace A GoAlertSchedule whose target-ref cache has never been warmed no longer deletes live targets that are still declared in spec. This is the case an operator restart reaches when it reconciles a schedule ahead of the GoAlertUser CRs it references: attribution falls back to the resolvedTargetRefs cache, and on a cold cache an unresolvable ref matches neither a fresh resolution nor a cache entry, so convergence removed it. Rotations received this grace in v0.9.0; schedules had the cache field but no warmth marker, and that asymmetry was the bug. The exposure was wider than first described. The AllUnresolved short-circuit did not protect the all-unresolvable case, because resolveTargets folds raw external targets into the same slice unconditionally — so a single Slack-channel target in spec left it non-empty, the guard never fired, and reconcile fell through to convergence with an empty cache. A cache-cold reconcile with any unresolved userRef now applies additions and rule updates, withholds every removal, names the withheld targets and the unresolved refs in a Warning ColdCacheGrace event, and marks the cache warmed so the grace is consumed exactly once. The guard keys off status.refTargetCacheWarmed directly, never off cache length: a never-warmed cache and a warmed-but-empty one are otherwise indistinguishable. Raw external targets were never at risk. New field: GoAlertSchedule.status.refTargetCacheWarmed. Every schedule predating this release has an unwarmed cache, so the first reconcile after upgrading is when the grace is most likely to fire. Epic goalert-provisioning-b6s.11.
-
v0.10.0
Release: v0.10.0c7f4b204 · ·v0.10.0 Closes the Heystaq integration-key report. Breaking: GoAlertService status no longer publishes the integration-key bearer token. Read the Secret named by secretRef instead. Key removal is now declarative but opt-in, defaulting to orphan, with a circuit-breaker refusing wholesale deletion on an empty spec. No API key reissue is required to upgrade.
-
v0.9.1
Release: v0.9.1f30eda0c · ·v0.9.1 GoAlertUser asks for a verification code once per contact method instead of reissuing one on every reconcile. GoAlert deletes an unverified SMS, VOICE or EMAIL contact method when its verification code expires -- deliberately, since v0.31.0. The operator treated that as drift, recreated the method and sent a fresh code, so a real person received a repeated text, phone call and email for hours in a loop only they could end, and each recreation destroyed the GoAlert message-log evidence that the sends had happened. Verification is now recorded against method identity and survives the method being deleted and recreated, so a code is requested once and never reissued. The person completes it from the GoAlert UI on their own schedule. The resting state is stable but not finished: the method sits in GoAlert unverified, so it will not notify anyone. A ContactMethodsVerified condition and a VerificationExpired event make that visible instead of silent. Ready stays True, because the object itself is synced. Also adds the skip-unverifiable-contact-methods annotation for teams who would rather the operator never create verifiable methods at all.
-
v0.9.0
Release: v0.9.00afd4808 · ·v0.9.0 Rotation participants and schedule targets converge on spec instead of accumulating additively. A user or target removed from spec is now removed from GoAlert even while a sibling ref is unresolved, and rotation participants follow declared spec.userRefs order -- which decides who is on call for the week containing spec.start. A cache-cold grace cycle protects live on-call rotations on the first reconcile after this upgrade: a rotation whose ref cache has never been warmed adds newcomers but removes nobody, then converges normally. Participant removal is now visible via the StaleParticipantsRemoved event and the Ready condition, with ColdCacheGrace distinguishing a cycle that left participants in place. Known limitation: schedule target convergence has no grace rule; see docs/adoption.md.
-
-
v0.8.3
Release: v0.8.3633442a3 · ·v0.8.3 Reconciles GoAlertService escalation policy and heartbeat timeout drift, which were detected but silently never applied while the controller reported success. Adds the deletion-policy annotation so a CR can be detached without destroying integration keys, and a per-CRD reference documenting which spec fields reconcile on update. No API-key rotation required; operation count stays at 41.
-
v0.8.2
Release: v0.8.204f4033b · ·v0.8.2 — stop the PartiallyResolved hot loop Fixed: - GoAlertSchedule diffs targets (and their rules) against GoAlert and writes only what differs, instead of rewriting every target on every reconcile. - Dependency-wait states back off from 30s to a 10-minute ceiling instead of polling forever. Applies to PartiallyResolved, AllUnresolved, UserNotFound and BlockedByDependency across all five resource controllers. Changed: - GetScheduleTargets query document now selects each target's rules. Operation count unchanged at 41; regenerate the API key via scripts/create-api-key.sh. Graceful fallback on an un-rotated key. Security: - golang.org/x/text 0.39.0 (GO-2026-5970), golang.org/x/net 0.56.0 (GO-2026-5026), Go builder image 1.26.5.
-
-
-
-
-
-
-
-
-
-