# Changelog

All notable changes to this chart are documented in this file.

## [1.0.14] - 2026-07-15

- `coralogixAlertsTemplate` now sets its own explicit `enabled: false` instead of omitting the key. Previously it inherited `basicTemplates.enabled`, so enabling the cpu/memory background-analysis templates (`basicTemplates.enabled: true`) also turned on the Coralogix alerts gate as a side effect. It now requires its own explicit `coralogixAlertsTemplate.enabled: true` to opt in, independent of the cpu/memory group flag.

## [1.0.13] - 2026-07-12

- Quote the `canary-by-header` / `canary-by-header-value` annotations rendered under `trafficRouting.nginx.additionalIngressAnnotations` (`| quote`). Previously a purely-numeric `canaryByHeaderValue` (e.g. a timestamp) rendered as an unquoted YAML scalar, which the Rollout CRD's schema rejects (`must be of type string`) even when the value was passed via `--set-string` on the Helm CLI, since raw template interpolation doesn't add quotes on its own.
- Add a `canary-header-value` label on the Rollout object's own `metadata.labels` (in addition to the existing `additionalIngressAnnotations` entry), set to `rolloutStrategy.canary.canaryByHeader.canaryByHeaderValue`. Only rendered when `canaryByHeader.enabled` is true. Lets tooling select/filter Rollouts by their current canary-header value directly, without reading the ingress annotations.

## [1.0.12] - 2026-07-01

- Add opt-in Coralogix open-alerts basic analysis template (`rolloutAnalysisTemplates.defaultTemplates.basicTemplates.templates.coralogixAlertsTemplate`) for jfrog-argo-rollouts, alongside the CPU/memory templates. When enabled it renders a web-provider `AnalysisTemplate` that fails the rollout while Coralogix has any active case for the current service and namespace. Opt-in (disabled by default).
- Remove the unused `service-name` arg from the built-in `basicTemplates` (cpu/memory and the new alerts gate); their `args:` block now renders only when `authToken` is set (carrying just `prom-auth-token`). Backward-compatible: none of these templates referenced `service-name` in their queries, and Argo silently ignores an undeclared `service-name` arg that a consumer still passes via `analysis`/`backgroundAnalysis` (it's not an error), so existing configs behave identically. Custom `rolloutAnalysisTemplates.templates` are unchanged and still declare `service-name`.
- Generalize the default-prom analysis-template loop: per-template `successCondition`/`failureCondition` (defaulting to `result[0] <= changeMax`), a per-template `enabled` that inherits `basicTemplates.enabled` when omitted and overrides it when set (so the alerts gate can be enabled independently of cpu/memory), and a per-template `promServerAddress` that overrides the group endpoint. Tidy the `defaultTemplates` values and drop the unused `defaultStepsEnabled` key. CPU/memory behavior is unchanged.
- Default `coralogixAlertsTemplate.name` is `jfrog-coralogix-alerts` (renamed from `jfrog-coralogix-open-alerts`). The chart now **enforces** that this template's `name` ends with the `-coralogix-alerts` suffix — failing the render otherwise — because Prizm keys off that suffix to present the AnalysisTemplate in its UI.
- Restructure the README into a short overview + a Documentation table of contents, moving the detailed content into per-topic docs under `docs/` (analysis templates, steps & background analysis, canary request job, rollout features).

## [1.0.11] - 2026-07-01

- Add `affinity` and `tolerations` under `rolloutAnalysisTemplates.canaryRequestJobTemplate`, rendered verbatim into the canary-request-job pod spec (`job.spec.template.spec`) when set. Defaults to `k8s.jfrog.com/subscription_type in (paying, paying-arm64)` node affinity plus matching `subscription_type` tolerations, steering the canary-request-job onto paying-tier nodes; set to `{}` / `[]` to opt out and let the scheduler pick any node.

## [1.0.10] - 2026-06-08

- Update the default CPU and memory analysis-template PromQL queries (`defaultTemplates.cpu`/`defaultTemplates.memory` in `_helpers.tpl`): join canary/stable pod metrics to `kube_pod_labels` via `and on(namespace, pod) max by (namespace, pod) (...)` and aggregate with `sum by (namespace, pod)` instead of the previous `* on(pod) group_left kube_pod_labels{...}`. Matching on `(namespace, pod)` makes the canary-vs-stable comparison correct when pod names collide across namespaces.

## [1.0.9] - 2026-06-07

- Add `logging_index: devops-infra` annotation on the canary-request-job pod template (`job.spec.template.metadata.annotations`) so canary-job pod logs are routed to the `devops-infra` logging index.
- Add pod-template labels `rollout-name` (from `rolloutStrategy.deploymentName`) and `canary-region` (from `canaryRegion`) on the canary-request-job pods for more context when filtering/monitoring.
- Name the canary-job metric after `canaryServiceName` (fallback `canary-job`) so the resulting pods are recognizable, e.g. `<analysis-run-uid>.<service>.<n>-<random>`. Underscores in the service name are replaced with hyphens (e.g. `mt_event` → `mt-event`) to keep the name DNS-1123 valid. Note: the leading UID is assigned by Argo Rollouts and cannot be changed from the chart.
- `rolloutAnalysisTemplates.canaryRequestJobTemplate.backoffLimit` and the new optional `ttlSecondsAfterFinished` are now rendered only when present in values (so a value of `0` is preserved). `ttlSecondsAfterFinished` lets Kubernetes delete the finished Job/pod after N seconds; when unset, pods persist until Argo Rollouts evicts the owning AnalysisRun via its run-history limit (default 5).

## [1.0.8] - 2026-06-04

- Update the default `promServerAddress` for the basic analysis templates from `https://ng-api-http.coralogix.us/metrics` to `https://api.us1.coralogix.com/metrics`.

## [1.0.7] - 2026-04-15

- Default `setAccountWeight` `timeout` when omitted is now **7200** seconds (2 hours); previously **1800** seconds (30 minutes). Explicit `timeout` values in values are unchanged.

## [1.0.6] - 2026-04-05

- Add configurable `rolloutStrategy.canary.stableMetadata` and `canaryMetadata` (each with `labels` and `annotations`) for Argo Rollouts stable and canary pod template metadata.
- Merge semantics: user-supplied labels and annotations are merged first; the chart then applies `role: stable` or `role: canary` last so `role` cannot be overridden from values.
- The rendered Rollout always includes `stableMetadata` and `canaryMetadata` with both `labels` and `annotations` keys.
