3.2 Bind base and deps in source
On this page you prove that the application source names the two inputs you already verified: the mirrored Hummingbird runtime, and the Lightwell pin.
Track 3 is application source. This is the second page. 3.1 Golden-path source put the repository on lw-student. The seeded Dockerfile still starts from UBI OpenJDK 21. You commit two edits on lw-student/spring-boot-lw-poc. The runtime FROM becomes the dest pull spec you recorded in 1.2 Mirror into the trust boundary. The default Maven property becomes 3.14.0.rhlw-00001 from LW-DEMO-0002. lightwell-pins.properties stays stale on purpose. 3.3 Live Renovate scores a bot pull request against that file.
Why this control exists
Later builds, SBOMs, and VEX read the pins that are in git. The dest Hummingbird digest from Track 1 and the Lightwell Network Remediated GAV from Track 2 become the application’s declared inputs on this page. A runtime FROM that is still UBI rebuilds the untrusted seed. A pin that lives only in an unused profile leaves the default on the affected line.
The seed stays on UBI so this page is a real edit. If the template already said FROM Hummingbird, Track 3 would be a screenshot of someone else’s pin.
The figure has three coordinates. This page is the right-hand box. The runtime FROM uses the dest pull spec from the middle box: the Route host, the path hi/openjdk, and the index digest. The repository name hummingbird-mirror is the Nexus Docker repository. It is not a segment of the image path. The left box is the published catalog from 1.1. A runtime FROM that still names registry.access.redhat.com fails the Check. The build stage stays on UBI until Track 4. You change the runtime stage on this page.
A Clearinghouse Premier member version would replace the same default GAV, beside the same dest FROM. The pins file stays untouched so 3.3 can prove the bot, including a later Premier bump.
|
A Python application binds the same way: the runtime |
In a customer engagement the base image is pinned in git by digest. You use the dest registry coordinates on the runtime stage.
Learning objectives
By the end of this module, you will be able to:
-
Replace the runtime
FROMwith the dest Hummingbird pull spec from 1.2 -
Set the default
commons.lang3.versioninpom.xmlto3.14.0.rhlw-00001 -
Leave
lightwell-pins.propertieson the stale seed for the Renovate bot -
Explain that a Clearinghouse Premier remediation is the same default-property change once the GAV is in the proxy
The seeded tree
Clone student_repo_url from ConfigMap demo-userinfo-gitea in namespace gitea. Success is a clone whose runtime FROM names ubi9/openjdk-21-runtime, whose default commons.lang3.version is 3.14.0, and whose pins file still shows 3.14.0.rhlw-00000 and an all-zero Hummingbird digest.
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
The runtime registry is the dest host from Track 1. dest_registry_repo is the Nexus Docker repository name, hummingbird-mirror. The image path is hi/openjdk. The DEST_PULLSPEC= line from the 1.2 copy-signatures log is the string to paste. This page uses dest_registry_host, the Route. Track 4 later retargets the runtime FROM to an internal ImageStream so the build still works after egress is closed.
Success is the dest host, the internal host, and a DEST_PULLSPEC= line when the 1.2 Job log is still on the cluster.
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
The block below is a FROM on a registry this cluster does not have. Pasting it as the runtime stage fails the Check.
# Worked example ONLY — fake registry. Pasting this as FROM still fails.
FROM registry.example.invalid/not-hummingbird:latest
Your change
Edit the clone at /tmp/spring-boot-lw-poc.
Change the runtime stage FROM. Leave the AS build line on UBI. The runtime line is the dest host, the path hi/openjdk, and the digest from DEST_PULLSPEC. A line that contains hummingbird-mirror, registry.access.redhat.com, or :latest fails the Check.
Change the default <commons.lang3.version> in pom.xml to 3.14.0.rhlw-00001. You already practiced this on ConfigMap stub-04-remediated-pin. This commit is the scored git copy. A profile that is never activated leaves the default on 3.14.0, and that default fails the Check.
Leave lightwell-pins.properties as the seed wrote it.
A Showroom shell has no TTY for an HTTPS password prompt, and a fresh clone may have no author identity. The next block sets both on this repository. A later Showroom restart stores the same author and Gitea credentials in ~/.gitconfig, so later modules can keep git commit and git push origin HEAD as written. The password is interpolated into the remote URL for this push. It does not belong in a committed file.
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}"
Success of the commit is a push of Dockerfile and pom.xml only.
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
Read the files from HEAD, so you are looking at the commit you pushed. Success is three facts. The runtime FROM is the dest registry, hi/openjdk, and a digest. The default pom property is 3.14.0.rhlw-00001. lightwell-pins.properties is still the stale seed.
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
A runtime FROM that is still ubi9/openjdk-21-runtime, or that names hummingbird-mirror or the worked-example host, fails the Check. The Validate Job grades those committed files. The next page still opens if you skip this one.
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.
Official documentation
-
Red Hat Hardened Images (the dest digest you bind)
-
Configure your Java build tool (the GAV you bind)
