Niklas Ye
989425e550
CI / chart (push) Successful in 1s
CI / security (push) Successful in 28s
CI / test (push) Successful in 2m13s
Release / test (push) Successful in 1m9s
Release / chart (push) Successful in 2s
Release / binaries (push) Successful in 1m41s
Release / image (push) Successful in 1m42s
Release / scan-image (push) Successful in 2s
Cosmetic, as ine78f494and4cec26e. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.10.2 that still says 0.10.1 tells a reader something false. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf.
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.10.2
|
|
appVersion: "v0.10.2"
|