3.2 Bind base and deps in source
Overview
Commit the dest Hummingbird FROM from 1.2 and the default Maven pin 3.14.0.rhlw-00001 on your Gitea app lw-student/spring-boot-lw-poc.
The seeded Dockerfile still uses UBI OpenJDK 21. lightwell-pins.properties is stale on purpose for 3.3. Do not edit that pins file here. Do not copy a sample FROM from Showroom.
Why it matters
TSSC is only as strong as the pins in source. You pin digests in git, not :latest. A UBI FROM or an unused Maven profile rebuilds the untrusted seed. Later hermetic build, SBOM, and VEX all read these files.
Lightwell Clearinghouse Premier member-specific versions would replace the default GAV the same way. They still sit next to the dest Hummingbird FROM.
What does it solve
-
Dockerfiles and Maven pins that still float
-
UBI
FROMon a public registry -
Unused profiles hiding the pin
Clone your app remote
export STUDENT_USER=student
: "${STUDENT_PASS:=$(oc -n gitea get configmap demo-userinfo-gitea -o jsonpath='{.data.student_password}')}"
: "${REPO_URL:=$(oc -n gitea get configmap demo-userinfo-gitea -o jsonpath='{.data.student_repo_url}')}"
rm -rf /tmp/spring-boot-lw-poc
git clone "${REPO_URL}" /tmp/spring-boot-lw-poc
cd /tmp/spring-boot-lw-poc
git remote -v
grep -n FROM Dockerfile
grep commons.lang3.version pom.xml | head -20
cat lightwell-pins.properties
Expect runtime FROM ubi9/openjdk-21-runtime and a default commons.lang3.version of 3.14.0 (affected upstream). 3.18.0 (or any newer Central line) is the wrong fix. The pin is not yet 3.14.0.rhlw-00001. Pins file should still show 3.14.0.rhlw-00000 and an all-zero Hummingbird digest.
dest_registry_repo is the Nexus Docker repository name (hummingbird-mirror), not the image path. Dest image path is hi/openjdk. Prefer the DEST_PULLSPEC= line from the 1.2 copy-signatures Job log.oc -n lightwell-repo get configmap demo-userinfo-lightwell-repo \
-o jsonpath='dest={.data.dest_registry_host}{"\n"}internal={.data.dest_registry_internal_host}{"\n"}'
echo 'Dest image path is hi/openjdk — not dest_registry_repo (hummingbird-mirror).'
echo '3.2 uses dest_registry_host (Route). 4.1 retargets runtime FROM to an internal ImageStream so 4.4 still works after 4.3.'
oc -n lightwell-repo logs job/oc-mirror-learner -c copy-signatures | grep '^DEST_PULLSPEC=' || true
Worked example (not the Check)
# Worked example ONLY — fake registry. Pasting this as FROM still fails.
FROM registry.example.invalid/not-hummingbird:latest
Your change: runtime FROM + default pin
-
Change only the runtime stage
FROM(leave theAS buildUBI line). Use dest host + pathhi/openjdk+ the internal digest from 1.2 (or pasteDEST_PULLSPEC). Do not putdest_registry_repo(hummingbird-mirror) in the image path. Do not reuse the publishedregistry.access.redhat.compin from 1.1, and not:latest. -
Change the default
<commons.lang3.version>inpom.xmlto the Track 2 pin (3.14.0.rhlw-00001). Do not stop at a profile that is never activated. You already practiced this on ConfigMapstub-04-remediated-pin; this commit is the scored git copy. -
Do not edit
lightwell-pins.properties.
git commit reports unknown author identity, or git push cannot read a username (Showroom has no TTY for HTTPS auth)cd /tmp/spring-boot-lw-poc
git config user.name student
git config user.email student@workshop.local
: "${STUDENT_USER:=$(oc -n gitea get configmap demo-userinfo-gitea -o jsonpath='{.data.student_username}')}"
: "${STUDENT_PASS:=$(oc -n gitea get configmap demo-userinfo-gitea -o jsonpath='{.data.student_password}')}"
hostpath="$(git remote get-url origin)"
hostpath="${hostpath#https://}"
hostpath="${hostpath#http://}"
git remote set-url origin "https://${STUDENT_USER}:${STUDENT_PASS}@${hostpath}"
A later Showroom restart stores the same author and Gitea credentials in ~/.gitconfig so later modules can keep git commit / git push origin HEAD as written.
cd /tmp/spring-boot-lw-poc
git add Dockerfile pom.xml
git status
git diff --cached
git commit -m "Bind dest Hummingbird runtime and Lightwell default pin"
git push origin HEAD
Check: committed files on your remote
cd /tmp/spring-boot-lw-poc
git fetch
git show HEAD:Dockerfile | grep -E '^FROM '
git show HEAD:pom.xml | grep -A1 commons.lang3.version | head -20
git show HEAD:lightwell-pins.properties
Pass when:
-
Runtime
FROMis dest registry +hi/openjdk+ digest (nothummingbird-mirror, notubi9/openjdk-21-runtime, not the worked-example host) -
Default pom property is
3.14.0.rhlw-00001 -
lightwell-pins.propertiesis still stale (bot work)
The Job also grades ConfigMap report-06-bind-base-deps key runtime_from. Set it to dest-digest. Empty or REPLACE_ME fails even if cluster state is correct. Do not copy validate-docs.
oc -n lw-poc-validate edit configmap report-06-bind-base-deps
The scored Check is Job validate-06-bind-base-deps in lw-poc-validate. Direct nav URLs still work (honor system). Unlimited retries. There is no Solve.
oc -n lw-poc-validate delete job validate-06-bind-base-deps --ignore-not-found
TPL='job-06.yaml'
oc -n lw-poc-validate get configmap validate-job-templates \
-o go-template="{{ index .data \"${TPL}\" }}" | oc create -f -
oc -n lw-poc-validate logs -f job/validate-06-bind-base-deps
Expect CHECK PASSED: before you continue. CHECK FAILED: names the object to fix. Delete the Job and create it again as often as you need.
Honor system: 3.3 still opens. Still-UBI runtime FROM fails this Check.
Callout: Python runtime FROM
A Python app binds the same way. Runtime FROM is the dest Hummingbird Python digest (not ubi9/python-* on a public registry). The pin still comes from 1.2. This Check is the Java OpenJDK Dockerfile.
Official documentation
-
Red Hat Hardened Images (the dest digest you bind)
-
Configure your Java build tool (the GAV you bind)
Key takeaways
-
TSSC source of truth is your Gitea remotes. Dest Hummingbird plus the Lightwell Network pin live there.
-
Clearinghouse Premier would change the same default property, not a side file.
-
3.3 still requires a bot PR on the pins file.
cd ~/ocp5-rhacs-showroom
bash setup/lab-cleanup.sh --module tssc-06
