Niklas Ye
e3ad19c110
CI / test (push) Successful in 4s
CI / chart (push) Successful in 1s
CI / security (push) Successful in 11s
Release / test (push) Successful in 9s
Release / chart (push) Successful in 2s
Release / binaries (push) Successful in 1m1s
Release / image (push) Successful in 1m25s
Release / scan-image (push) Successful in 24s
Cosmetic, as in041e159and989425e. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. 0.11.0 never reached the registry -- its release run failed at the test gate -- so the placeholder moves on to the version that will.
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.11.1
|
|
appVersion: "v0.11.1"
|