3.3 Live Renovate
You have pushed the verified runtime image and selected dependency version into application source. Now review and merge a real Renovate pull request against lightwell-pins.properties in lw-student/spring-boot-lw-poc. Use the Gitea UI for the review and the Showroom clone from module 3.2 to inspect the merged result.
Why this control exists
An automated update gives the team a proposed version change with reviewable history. Renovate discovers available versions, opens a pull request, and leaves the merge decision to you. Your job is to compare the proposed values with the evidence from Tracks 1 and 2 before accepting them.
The workshop seeds two stale values in lightwell-pins.properties. Renovate groups their updates into one pull request:
| Property | Starting value | Expected update |
|---|---|---|
|
|
|
|
An all-zero SHA-256 digest |
The destination digest verified in Track 1. |
This exercise establishes the bot’s update and your review of it. The properties file does not automatically update the runtime FROM or default Maven property; you committed those separately in module 3.2.
Learning objectives
By the end of this module, you will be able to:
-
Locate the workshop Renovate workload and identify its pull request on Gitea.
-
Compare both proposed pin values with the evidence from Tracks 1 and 2.
-
Merge the bot’s pull request and refresh your local application clone.
-
Identify the updated values and the bot-authored commit in the merged history.
The bot on this cluster
The chart is off unless components.renovate is enabled on this cluster. If the CronJob is missing, tell an instructor. A pull request you author yourself does not demonstrate an automated update.
The output should show a CronJob in namespace renovate, ConfigMap lab-renovate, and a short Markdown example of the pull request format.
oc -n renovate get cronjob
oc -n renovate get configmap lab-renovate -o yaml
oc -n renovate get configmap renovate-docs \
-o jsonpath='{.data.example-renovate-pr\.md}'
Exercise
Review both proposed updates
In Gitea, open lw-student/spring-boot-lw-poc and then Pull Requests. Select the pull request authored by renovate-bot targeting main. Open its changed-files view and inspect lightwell-pins.properties.
Compare the commons-lang3 value with the selected version in ~/lightwell-dependencies/pom.xml. Compare hummingbird-digest with the sha256: portion of Track 1’s verified destination pull spec. Read the report again if needed:
oc -n lw-poc-validate get configmap report-02-hummingbird-mirror \
-o jsonpath='status={.data.status}{"\n"}destination={.data.destination_pullspec}{"\n"}'
Require status verified and matching values for both updates. If the PR changes only one pin or proposes a different value, investigate before merging. Do not hand-edit the properties file to imitate the bot update.
Merge the reviewed pull request
After both comparisons match, merge the pull request in Gitea using the merge-commit option so the bot’s original commit remains visible. Record the PR number and merge commit in your notes.
The screenshot illustrates a merged bot pull request. The Files Changed tab opens the diff, Commits shows the bot commit, and the purple Merged badge confirms the merge. Inspect your own PR author, diff, and merged status; the screenshot is not evidence for your repository.
If no PR is open, check the merged PRs first in case you already completed this exercise. Otherwise, the CronJob runs about every 20 minutes. Inspect its recent Jobs and read the logs for the actual Job name shown:
oc -n renovate get jobs --sort-by=.metadata.creationTimestamp
Run oc -n renovate logs job/<job-name> with that name. A missing CronJob requires instructor help. For a failed run, check the log for access to Gitea, Nexus Maven metadata, or the mirrored image. Confirm that you granted the bot write access in module 3.1 and Track 1 completed the mirror. Let the next scheduled run retry after the prerequisite is corrected.
Refresh your application clone
Check git status --short before pulling. If you have unfinished edits, complete and preserve them before updating the clone.
After the merge, refresh the clone from 3.2. git log -1 shows the latest commit. Success is a properties file that has moved off rhlw-00000 and the all-zero digest, and a renovate-bot commit on that file. The second git log lists commits for lightwell-pins.properties. Look for the bot-authored update; a merge commit may also appear in the history.
cd /home/lab-user/lightwell-workspace/spring-boot-lw-poc
git fetch origin
git checkout main
git pull --ff-only origin main
git log -1 --format='%an %ae %s'
git log --format='%h %an %ae %s' -- lightwell-pins.properties
cat lightwell-pins.properties
Review
Inspect the fetched remote branch so your evidence reflects what reached Gitea. The command displays the merged pins and the history of that file, including each commit’s author.
cd /home/lab-user/lightwell-workspace/spring-boot-lw-poc
git fetch origin
git rev-parse HEAD origin/main
git show origin/main:lightwell-pins.properties
git log origin/main --format='%h %an %ae %s' -- lightwell-pins.properties
printf '\nExpected image digest from Track 1:\n'
oc -n lw-poc-validate get configmap report-02-hummingbird-mirror \
-o jsonpath='status={.data.status}{"\n"}destination={.data.destination_pullspec}{"\n"}'
Compare commons-lang3 with the version selected in module 2.2: 3.14.0.rhlw-00001. Compare hummingbird-digest with the complete sha256: portion of the verified destination above. Both must match exactly; merely replacing the stale values is insufficient. HEAD and origin/main should match after your pull. Stop and investigate any command error, missing value, or mismatch.
In Gitea, open the PR you reviewed and confirm its author is renovate-bot, its target is main, and its status is Merged. Inspect its diff for both pin changes and match the bot’s commit with the file history above. A Git author name alone is not proof that the bot opened the PR, so review both the PR and the committed result.
Record the PR number, merge commit, and the two compared values in your notes. Explain the two roles: Renovate proposed the update, and you reviewed and merged it. You are ready for Track 4 when the merged PR and remote file agree with your evidence. There is no validation Job or report token to submit. A manually recreated diff is not a substitute for completing the bot review exercise.
Carry the result into Track 4
You now have student-owned source, committed base and dependency choices, and a reviewed automated update. Keep the application clone. Track 4 starts from this source and removes the public fetches and build overrides that still prevent a hermetic build.
|
This lab uses an in-cluster Renovate CronJob. MintMaker is the related service in the Konflux mapping; hosted Konflux is not installed here. A customer may use the same review pattern with Artifactory or a private Clearinghouse version. Python uses a requirements file instead of this Java exercise. See Konflux mapping. |
Official documentation
-
Lightwell Network Java repository (the metadata Renovate reads through Nexus)
-
Konflux mapping (MintMaker maps to this CronJob)
