jklein
6371f60eeb
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 8s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 7s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 20s
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Successful in 2m52s
calibre-web-automated 7.0.0, minecraft-server 6.0.0 and urlaubsverwaltung
10.0.0 each majors: an installation that renders today with an empty itemPath
stops rendering. searxng 1.0.6 is documentation only - its valkey reference is
correctly optional and stays gated by {{- if }}.
Every message names the values path. values.yaml now says per key why it is
required, reusing the wording the charts' NOTES.txt already carry. The
hand-rolled "cwaSecretRef IS UNSET" block in calibre-web-automated's NOTES.txt
is gone: after the guard the render aborts first and that block is
unreachable. minecraft-server's note stays true and now points at the guard.
No "required" array in the schemas, and README guideline 12 now says why. The
plan called for one; measuring it showed it could never fire: the key ships as
null, so it is present at validation time, and JSON Schema's required tests
presence, not null-ness. Making it fire means either dropping the null default
or narrowing the type to "string", and both turn helm lint --strict red on the
chart's own defaults. The schema therefore describes the key as required and
required() enforces it. The README bullet on how null reaches the schema was
also wrong in the case it was being applied to - a null chart default is not
coalesced away - and now distinguishes the three cases.
searxng: the claim "charts in this repo have no dependencies (README,
guideline 13)" in the valkey template, in values.yaml and twice in _helpers.tpl
has been false since #214 and cited the wrong guideline; dependencies are
admissible and are guideline 14. The same sentence survives in other charts'
helpers and needs its own round.
31 lines
1.5 KiB
YAML
31 lines
1.5 KiB
YAML
apiVersion: v2
|
|
name: minecraft-server
|
|
description: A Helm chart for deploying a itzg/minecraft-server
|
|
icon: https://avatars.githubusercontent.com/u/988985
|
|
|
|
type: application
|
|
|
|
# ONLY THE NEWEST JAVA LINE IS MAINTAINED (chart 5.0.0, issue #158).
|
|
# appVersion is the image tag and therefore fixes the JVM. Up to chart 4.1.0 the
|
|
# chart was published once per line (java8 / java17 / java21 / java25) out of
|
|
# this single directory, which is what made the lines drift apart: whatever
|
|
# change landed while a line happened to lie in the directory reached that line
|
|
# only. That is over. This directory carries exactly one line - the newest -
|
|
# and it is the only one that gets chart changes.
|
|
# The older lines stay published as frozen artifacts and are still installable:
|
|
# java8 and java17 at 4.0.0, java21 at 4.1.0. They will not be updated again.
|
|
# To run an older JVM with the CURRENT chart, set image.tagOverride in values
|
|
# instead of installing a frozen chart version; the chart then checks that
|
|
# minecraft.version fits the line of that tag and fails the render if it does
|
|
# not.
|
|
# Since chart 2.0.0 the tag is a DATED upstream release ("<release>-java<N>")
|
|
# instead of the rolling line tag ("java<N>"): the rolling tags are rebuilt
|
|
# continuously, so a pod restart could pull a different image than the last one
|
|
# without anything being recorded anywhere. The dated tags are immutable, so the
|
|
# image is now pinned by the chart version like every other chart in this repo.
|
|
version: 6.0.0+up2026.8.2.java25
|
|
appVersion: "2026.8.2-java25"
|
|
|
|
maintainers:
|
|
- name: jklein
|