3.1 Golden-path source

Tracks 1 and 2 produced a verified Hummingbird destination and an exact Lightwell dependency version. Now use Red Hat Developer Hub (RHDH) to create the Java application repository that will record those choices. Work in Developer Hub and Gitea in your browser, and use the Showroom terminal for the explicit permission and Git commands below.

This module creates and registers the application, grants Renovate access, and prepares the stage and production GitOps repositories. Module 3.2 commits the base image and dependency version; module 3.3 reviews and merges a Renovate pull request.

Why this control exists

Templating gives each application a consistent starting point: prepared source code, build files, and deployment configuration that your team can reuse. RHDH makes this process visible through a Software Template. You supply parameters, watch the template fetch and render source, publish it to Gitea, and register the resulting component in the Software Catalog. The catalog records ownership and provides a link back to the source repository.

Renovate maintains recorded dependency and image versions over time by proposing pull requests. You review the proposed changes before merging them. In this lab, module 3.3 compares the bot’s updates to lightwell-pins.properties with your earlier evidence. That file does not automatically rewrite the Dockerfile or POM; you edit those in module 3.2. A template provides a starting point, while a reviewed update records a deliberate maintenance decision. Neither establishes that every input is safe without the later verification and build exercises.

The operator prepares workshop-templates/lightwell-java-service, the parameterized source used by RHDH. Developer Hub publishes your application to lw-student/spring-boot-lw-poc. The stage and production GitOps templates are separate repositories that you copy with Git commands later on this page. You do not run student-seed-from-templates.sh or pre-create the application repository.

Three RHDH actions fetch and render the skeleton then publish the student application and register its catalog entry; separate Git commands copy stage and production repositories
Figure 1. RHDH creates the application and catalog entry; you copy the GitOps repositories separately.

Learning objectives

By the end of this module, you will be able to:

  • Explain how an RHDH Software Template fetches, publishes, and registers application source.

  • Prepare the Gitea organization and verify the publishing account’s access.

  • Generate the Java application through Developer Hub and locate its catalog entry.

  • Grant Renovate write access and copy the two GitOps templates with ordinary Git pushes.

  • Compare the generated files and repository locations with the expected starting state.

Discover the lab coordinates

Run these commands in Showroom. The output should identify the Gitea and Developer Hub URLs, the student organization, the application remote, and the RHDH skeleton remote. Each value must be present. Keep passwords out of notes and screenshots.

oc -n gitea get configmap lab-gitea \
  -o jsonpath='gitea={.data.gitea_url}{"\n"}user={.data.student_username}{"\n"}org={.data.student_gitea_org}{"\n"}app={.data.student_repo_url}{"\n"}skeleton={.data.template_skeleton_repo_url}{"\n"}'
oc -n rhdh get configmap lab-rhdh \
  -o jsonpath='developer_hub={.data.rhdh_url}{"\n"}template={.data.software_template}{"\n"}publisher={.data.scaffolder_username}{"\n"}gitea_plugin_configured={.data.gitea_scaffolder_enabled}{"\n"}'

Open Gitea and sign in as student with your lab password. Provisioning should already have created this account. If login fails, ask the instructor to repair it before continuing. The legacy account-repair script can reset an existing password; account repair is not part of this exercise.

Open Developer Hub and choose the lab’s Guest sign-in. Open Self-service (the plus icon in the top bar, labeled Create in some versions) and confirm Lightwell Java Service is listed. On Developer Hub’s /create/actions page, confirm that fetch:template, publish:gitea, and catalog:register are available. The ConfigMap flag describes configuration only; the actions page confirms that the running backend loaded the actions. If the template or an action is missing, stop and ask the instructor to check provisioning.

On the actions page, use Search for an action and select publish:gitea. Repeat for fetch:template and catalog:register. You are checking actions installed by provisioning; students do not install or enable plugins.

RHDH Installed actions page with publish:gitea selected and its repository inputs visible
Figure 2. The installed publishing action is a prerequisite for the template.

Exercise

Prepare the organization and publishing access

In Gitea, use + → New Organization to create the public organization lw-student. If it already exists, inspect it and preserve its repositories. Do not create spring-boot-lw-poc: Developer Hub will create it. If the application already exists from an earlier attempt, inspect its contents and the RHDH task history with the instructor; do not delete it or force-push over it to repeat this exercise.

Gitea organization form with the name lw-student

Developer Hub publishes through its configured Gitea service account. The following commands authenticate as the student organization owner, find the exact Owners team, and add the publishing account. They do not read the publisher’s password. Stop on any failed command; do not continue with an empty team ID.

GITEA_URL="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.gitea_url}')"
STUDENT_USER="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.student_username}')"
STUDENT_PASS="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.student_password}')"
LEARNER_ORG="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.student_gitea_org}')"
PUBLISHER="$(oc -n rhdh get configmap lab-rhdh -o jsonpath='{.data.scaffolder_username}')"
API="${GITEA_URL%/}/api/v1"
: "${PUBLISHER:?Missing scaffolder_username; ask the instructor to update lab-rhdh}"
TEAMS_FILE="$(mktemp)"
curl --fail --silent --show-error --user "$STUDENT_USER:$STUDENT_PASS" \
  "$API/orgs/$LEARNER_ORG/teams" -o "$TEAMS_FILE" &&
OWNER_TEAM_ID="$(python3 -c 'import json,sys; teams=[t for t in json.load(open(sys.argv[1])) if t["name"].lower()=="owners"]; assert len(teams)==1, "Expected one Owners team"; print(teams[0]["id"])' "$TEAMS_FILE")" &&
curl --fail --silent --show-error --user "$STUDENT_USER:$STUDENT_PASS" \
  -X PUT "$API/teams/$OWNER_TEAM_ID/members/$PUBLISHER" \
  -o /dev/null -w 'Publishing account membership: HTTP %{http_code}\n'

Expect HTTP 204 or 200. In Gitea, open the organization’s Teams → Owners and confirm the publishing account is listed. This is a claim-local workshop arrangement; a customer should scope its publishing identity to the organizations it manages.

Create the application through Developer Hub

In Developer Hub, open Self-service and select Choose on the Lightwell Java Service card. This opens the template wizard; Import an existing Git repository serves a different workflow.

RHDH Self-service page showing the Lightwell Java Service card and its Choose button
Figure 3. Choose the workshop template from Self-service.

Keep the workshop defaults:

Field Value

Name and repository

spring-boot-lw-poc

Gitea organization

lw-student

Default branch

main

Maven group ID and Java package

com.redhat.lightwell.workshop

Java source path

com/redhat/lightwell/workshop

Default Maven settings profile

lightwell-validated

In Lightwell Network, keep Validated (upstream-parity rebuilds), the display label for lightwell-validated. On Publication (Gitea), confirm the destination below. The organization must already exist, while the application repository must not.

RHDH Publication Gitea step showing lw-student as organization and spring-boot-lw-poc as repository with main as default branch
Figure 4. Publish to the student organization, with main as the default branch.

Select Review and compare the summary with the table above. The screenshots show the wizard before submission; they do not prove that a repository or catalog entry was created.

RHDH review screen listing the Java service defaults and Gitea destination with the Create button
Figure 5. Review the values before selecting Create.

Select Create to start the task. Watch the task steps: Fetch Lightwell Java skeleton renders the template, Publish to Gitea creates and pushes the application repository, and Register in Software Catalog registers catalog-info.yaml.

Success means all three steps complete and the task offers Repository and Open in catalog links. Open both. Confirm the repository belongs to lw-student and the catalog component is spring-boot-lw-poc. Record the task link and catalog link in your notes. If publishing succeeds but registration fails, preserve the repository and ask the instructor to repair catalog registration; repeating creation against an existing repository is not a clean retry.

Give Renovate access to propose updates

RHDH creates the application; you now explicitly grant the bot write access. Continue in the same Showroom shell. Expect HTTP 204 or 200, then verify the collaborator in Gitea’s application repository settings.

APP_REPO="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.student_repo_name}')"
RENOVATE_BOT="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.renovate_bot_username}')"
: "${APP_REPO:?Missing application repository name}"
: "${RENOVATE_BOT:?Missing Renovate bot username}"
curl --fail --silent --show-error --user "$STUDENT_USER:$STUDENT_PASS" \
  -X PUT -H 'Content-Type: application/json' -d '{"permission":"write"}' \
  "$API/repos/$LEARNER_ORG/$APP_REPO/collaborators/$RENOVATE_BOT" \
  -o /dev/null -w 'Renovate collaborator: HTTP %{http_code}\n'

If the bot account is missing or the request fails, ask the instructor to check Renovate provisioning. Do not merge its PR until module 3.3, after completing module 3.2.

Prepare the stage and production GitOps repositories

The current Software Template publishes the application only. In Gitea, create two public, empty repositories under lw-student: gitops-spring-boot-lw-poc and gitops-prod-spring-boot-lw-poc. Leave the README checkbox clear. If either repository already contains work, inspect it and skip its initialization below.

Read the prepared template URLs and the destination URLs from lab-gitea. Clone the full template history, retain the template as a read-only reference named template, and add the student repository as origin. These commands use a fresh directory for this attempt. Git uses Showroom’s credential helper; keep both remote URLs free of passwords. Run bash /usr/local/libexec/lab-git-setup.sh to refresh it before continuing. See Git authentication and cleanup for its lab storage boundary.

STAGE_TEMPLATE="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.template_gitops_repo_url}')"
STAGE_REPO="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.student_gitops_repo_url}')"
PROD_TEMPLATE="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.template_prod_gitops_repo_url}')"
PROD_REPO="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.student_prod_gitops_repo_url}')"
GITOPS_DIR="$(mktemp -d "$HOME/lightwell-gitops.XXXXXX")"
bash /usr/local/libexec/lab-git-setup.sh
printf 'GitOps working directory: %s\n' "$GITOPS_DIR"

Copy the stage template. Expect a successful push creating main. An ordinary push refuses a conflicting history; investigate a rejection instead of adding --force.

git clone --branch main "$STAGE_TEMPLATE" "$GITOPS_DIR/stage" &&
git -C "$GITOPS_DIR/stage" remote rename origin template &&
git -C "$GITOPS_DIR/stage" remote add origin "$STAGE_REPO" &&
git -C "$GITOPS_DIR/stage" push -u origin HEAD:main

Repeat for production. The two destinations must be different repositories.

git clone --branch main "$PROD_TEMPLATE" "$GITOPS_DIR/prod" &&
git -C "$GITOPS_DIR/prod" remote rename origin template &&
git -C "$GITOPS_DIR/prod" remote add origin "$PROD_REPO" &&
git -C "$GITOPS_DIR/prod" push -u origin HEAD:main
unset STUDENT_PASS

Review

In the RHDH task, confirm all three steps completed. Follow its catalog link and inspect the component’s name, owner, and source location. Follow the repository link and compare it with student_repo_url below. It must point to the student application, while template_skeleton_repo_url points to the source template.

oc -n gitea get configmap lab-gitea \
  -o jsonpath='app={.data.student_repo_url}{"\n"}skeleton={.data.template_skeleton_repo_url}{"\n"}'
STUDENT_REPO_URL="$(oc -n gitea get configmap lab-gitea -o jsonpath='{.data.student_repo_url}')"
git ls-remote --exit-code "$STUDENT_REPO_URL" refs/heads/main

The Git command must print a commit hash and refs/heads/main. Inspect these files on that branch in Gitea:

File Expected starting state

catalog-info.yaml

Component spring-boot-lw-poc with the owner selected in RHDH; no unresolved template expressions.

pom.xml

Default commons.lang3.version is 3.14.0.

Dockerfile

Runtime uses ubi9/openjdk-21-runtime.

renovate.json

Custom managers watch lightwell-pins.properties.

lightwell-pins.properties

Commons Lang ends in rhlw-00000; Hummingbird digest is all zeros.

.tekton/pipeline.yaml and Dockerfile.known-bad

Build exercise files are present for Track 4.

Confirm renovate-bot has write access. Compare the local template commit with the remote main for each GitOps repository; the two hashes in each pair should match immediately after copying.

git -C "$GITOPS_DIR/stage" rev-parse HEAD
git ls-remote --exit-code "$STAGE_REPO" refs/heads/main
git -C "$GITOPS_DIR/prod" rev-parse HEAD
git ls-remote --exit-code "$PROD_REPO" refs/heads/main

An error, empty output, unresolved template expression, or missing file needs investigation before continuing. Keep the task and catalog links, repository URLs, and commit hashes in your notes. These observations are your review evidence; there is no validation Job or report token to submit.

Continue to module 3.2 when the catalog registration, application starting files, bot access, and both GitOps copies are confirmed. The initial source deliberately leaves the base and dependency edits for you.

Official documentation