Niklas Ye
fcc4997dee
CI / chart (push) Successful in 1s
CI / test (push) Successful in 8s
CI / security (push) Successful in 20s
Release / test (push) Successful in 7s
Release / chart (push) Successful in 2s
Release / binaries (push) Successful in 14s
Release / image (push) Successful in 1m6s
Release / scan-image (push) Successful in 3s
make helm-package passes --version and --app-version from the tag, so these fields decide nothing about what is published. They are moved anyway because a tree heading for v0.45.0 that says 0.44.1 tells the reader something false. Claude-Session: https://claude.ai/code/session_016mBLURvJoMuUEr9cB2RpUN
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.45.0
|
|
appVersion: "v0.45.0"
|