Niklas Ye
71d7e1853a
CI / chart (push) Successful in 1s
CI / security (push) Successful in 14s
CI / test (push) Successful in 2m41s
Release / test (push) Successful in 4s
Release / chart (push) Successful in 2s
Release / binaries (push) Successful in 18s
Release / image (push) Successful in 56s
Release / scan-image (push) Successful in 5s
Cosmetic: make helm-package sets the published version and appVersion from the tag, so these two fields decide nothing (see the comment above them). Kept in step anyway, same as734cd9cand43f0044, so a tree heading for v0.22.0 doesn't say 0.21.0. Claude-Session: https://claude.ai/code/session_01MMados3BD1oSjevHxbmVqU
20 lines
1007 B
YAML
20 lines
1007 B
YAML
apiVersion: v2
|
|
name: terdut-server
|
|
description: A Helm chart for Terminal Duty — on-call alert management server
|
|
type: application
|
|
# These two are placeholders for a local `helm install ./charts/terdut-server`, not the
|
|
# released values. .gitea/workflows/release.yaml rewrites both from the git tag when it
|
|
# publishes, so the chart version always equals the app version.
|
|
#
|
|
# They are kept in step with the tag anyway. Being read is the only thing these two lines
|
|
# do -- `helm package --version --app-version` sets the published values from the tag and
|
|
# never consults these -- and a tree heading for a numbered release that states an older
|
|
# number tells its reader something false. They said 0.9.0 and "latest" until 2026-09-01,
|
|
# through two releases.
|
|
#
|
|
# appVersion and image.tag in values.yaml no longer agree, and that is not an oversight:
|
|
# image.tag stays "latest", which is what a local install actually pulls. appVersion is
|
|
# metadata and drives nothing.
|
|
version: 0.22.0
|
|
appVersion: "v0.22.0"
|