Stefan Grönke ba93207b77 Add sealed CI integration: a GitHub Action and a GitLab CI template ... scripts/validate.sh is the engine behind both platforms: download the released standalone jar and the validation configuration (SHA-256-verified when pinned), validate each document, print PASS/FAIL with the failing rule ids and fail on any rejection. The GitHub Action (action.yml) maps its inputs onto the script's environment; the GitLab template fetches the same script from this repository at KOSIT_SCRIPT_REF and drives it with the same variables, so both platforms run identical logic. With Docker available the action executes each validation sealed (the "sealed" input, default "auto"): inside an eclipse-temurin:21-jre container without network access, a read-only root and no capabilities, with only the jar, the configuration and a scratch directory mounted; downloads always happen outside the container, so the validator itself never touches the network, and the host JVM setup is skipped entirely for "sealed: always". The image tag pins the Java 21 JRE contract and floats the patch level: the released jars are the checksummed artifacts, the runtime is a security-patch channel; an "image" input (KOSIT_IMAGE on GitLab) accepts a digest-pinned reference for stricter policies. The GitLab job image is the same runtime, giving both platforms an identical execution environment, and a devcontainer provides the matching Maven and Java setup for development. The action self-test validates a conformant XRechnung reference instance and asserts a corrupted one is rejected, exercising the sealed path through the empty-input fallback and an explicit image override, plus the host path.		2026-07-23 10:34:59 +00:00
..
validate.sh	Add sealed CI integration: a GitHub Action and a GitLab CI template	2026-07-23 10:34:59 +00:00