Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 9s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 5s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 11s
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Failing after 1m38s
49 lines
2.1 KiB
YAML
49 lines
2.1 KiB
YAML
# CI values for the valkey install-test. The PERSISTENT variant on purpose: it is
|
|
# the chart's default and the only risky path there is (a provisioned PVC, the
|
|
# pod's fsGroup against it, an append-only file created on a volume the container
|
|
# did not create). The machinery can run one variant per chart, so the
|
|
# non-persistent path is covered by a local render only - named as a known gap in
|
|
# the PR that introduced this chart.
|
|
secrets:
|
|
authSecretRef: op://ci/valkey
|
|
|
|
persistence:
|
|
enabled: true
|
|
appendonly: true
|
|
# k3d's dynamic provisioner. The chart's default, longhorn-encrypted-ns, does
|
|
# not exist on the runner, and a pre-bound hostPath PV would be worse than this
|
|
# one: the kubelet does not apply fsGroup to a hostPath volume at all, so the
|
|
# test would silently stop exercising the ownership path it is here for.
|
|
storageClass: local-path
|
|
size: 128Mi
|
|
|
|
valkey:
|
|
# TEMPORARY, REVERTED IN THIS PR: readiness authenticates with a deliberately
|
|
# wrong password while the server keeps the right one, to prove in the cluster
|
|
# that this probe CAN fail. Expected: startup passes, readiness fails with
|
|
# "NOAUTH Authentication required.", the pod stays 0/1 and the rollout wait
|
|
# times out.
|
|
readinessProbe:
|
|
exec:
|
|
command:
|
|
- /bin/sh
|
|
- -ec
|
|
- VALKEYCLI_AUTH=deliberately-wrong-password valkey-cli -e -p 6379 ping | grep -qx PONG
|
|
# Small, so the whole thing stays inside the runner's budget. It still
|
|
# exercises the derivation: 64Mi x limitFactor 3 = 192Mi limit, maxmemory =
|
|
# 0.75 x that = 144Mi - and the render aborts if a configured maxmemory ever
|
|
# ends up above the limit.
|
|
resources:
|
|
requests:
|
|
cpu: 50m
|
|
memory: 64Mi
|
|
ephemeral-storage: 32Mi
|
|
|
|
# Left ON, although nothing in the test connects from another namespace: the
|
|
# point here is that the object is accepted and does not keep the pod's own
|
|
# traffic (the exec probes are local to the pod and unaffected) from working.
|
|
# Whether the policy actually FILTERS is a property of the cluster's CNI and is
|
|
# not claimed by this test.
|
|
networkPolicy:
|
|
enabled: true
|