jeffersonlab/srm repository overview

⁠srm

A Jakarta EE 10⁠ web application for managing system readiness at Jefferson Lab built with the Smoothness⁠ web template.

• Overview⁠
• User Guide⁠
• Quick Start with Compose⁠
• Install⁠
• Configure⁠
• Build⁠
• Develop⁠
• Release⁠
• Deploy⁠
• See Also⁠

⁠Overview

The System Readiness application allows machine operators and management to determine machine readiness. The app inventories all systems of the machine and organizes systems into a hierarchy of categories. Further, systems are assigned individual components to increase readiness specificity. To aid in answering the more common question of where can beam be sent, each component is associated with zero or more beam destinations. Component readiness is determined by System Responsible Groups, and each component has an ordered set assigned. Each Responsible Group is associated with a set of group leaders, who are authorized to mark final readiness.

See the User Guide⁠ for how to use it.

⁠Quick Start with Compose

1. Grab project

git clone https://github.com/JeffersonLab/srm
cd srm

1. Launch Compose⁠

docker compose up

1. Navigate to page

http://localhost:8080/srm

Note: Login with demo username "jdoe" and password "password".

⁠Ports

The containers publish these ports on the host, listening only on its local address (127.0.0.1), so other computers can't reach the demo database, accounts, and management consoles. To use them from another computer, forward them over SSH, such as ssh -N -L 8443:localhost:8443 -L 8081:localhost:8081 <host> for the app and Keycloak. If another project already uses some of them, or you run a second copy of the demo, set other ports in a .env file next to compose.yaml, which Compose reads, or in the environment:

For example, a .env with:

SRM_HTTPS_PORT=18443
SRM_HTTP_PORT=18080
SRM_KEYCLOAK_PORT=18081

The app and Keycloak are set up for the ports you choose, so log in at https://localhost:<SRM_HTTPS_PORT>/srm.

Compose names the containers, network, and images after the project's directory, such as srm-oracle-1, so a copy in another directory, such as a git worktree, gets its own.

See: Docker Compose Strategy⁠

⁠Install

This application requires a Java 17+ JVM and standard library to run, plus a Jakarta EE 10 application server (developed with Wildfly).

1. Install service dependencies⁠
2. Download Wildfly 37.0.1⁠
3. Configure⁠ Wildfly and start it
4. Download srm.war⁠ and deploy it to Wildfly
5. Navigate your web browser to localhost:8080/srm⁠

⁠Configure

⁠Configtime

Wildfly must be pre-configured before the first deployment of the app. The wildfly setup functions⁠ can be used to accomplish this. See the Dockerfile⁠ for an example.

⁠Runtime

Uses the Smoothness Environment Variables⁠ plus the following application specific:

There are some Settings⁠ in the database as well, which an admin edits on the Setup tab; see the User Guide's Administration⁠ page.

⁠Roles

Users with the srm-admin role are admins, who set up everything. A branch admin sets up one branch: a top-level category, such as Hall A, with the categories, systems and components below it. A branch's admins are the users with its admin role, which an admin sets with the Admin Role field when adding or editing the top-level category on the Setup > Category Tree page. Any role of the identity provider can be used, so a new branch admin role needs no code change. In their branch, a branch admin can also sign off a component as Ready or N/A for any responsible group, which otherwise takes an admin or a leader of the group.

⁠Database

This application requires an Oracle 19+ database with the following schema⁠ installed. The application server hosting this app must also be configured with a JNDI datasource.

⁠Build

This project is built with Java 21⁠ (compiled to Java 17 bytecode), and uses the Gradle 9⁠ build tool to automatically download dependencies and build the project from source:

git clone https://github.com/JeffersonLab/srm
cd srm
gradlew build

Note: If you do not already have Gradle installed, it will be installed automatically by the wrapper script included in the source

Note for JLab On-Site Users: Jefferson Lab has an intercepting proxy⁠

See: Docker Development Quick Reference⁠

⁠User Guide website

The user guide⁠ is Markdown, readable on GitHub, and also built into a website with Zensical⁠ (zensical.toml⁠). With uv⁠ installed:

uv run --locked zensical build --strict

builds it into site/, as CI does; --strict fails on a link to a missing page or heading. uv run --locked zensical serve previews it at http://localhost:8000⁠.

CI builds it and each release publishes it with the user guide workflows⁠ of general-workflows.

⁠Develop

In order to iterate rapidly when making changes it's often useful to run the app directly on the local workstation, perhaps leveraging an IDE. In this scenario run the service dependencies with:

docker compose -f deps.yaml up

Note: The local install of Wildfly should be configured⁠ to proxy connections to services via localhost and therefore the environment variables should contain:

KEYCLOAK_BACKEND_SERVER_URL=http://localhost:8081
FRONTEND_SERVER_URL=https://localhost:8443

Further, the local DataSource must also leverage localhost port forwarding so the standalone.xml connection-url field should be: jdbc:oracle:thin:@//localhost:1521/xepdb1. These are the default ports⁠; use yours if you set others.

The wildfly-lib.sh⁠ setup functions can be used to set up a local instance of Wildfly, as the Dockerfile⁠ does.

The unit tests run with gradlew build, or alone with gradlew test, and need no database, Wildfly, or containers.

The integration tests run against the app and its services in containers, built from source, and are not part of gradlew build:

docker compose -f build.yaml up -d --build
gradlew integrationTest

They wait up to 10 minutes for the services to start (set SRM_READY_TIMEOUT_SECONDS to change that), then log in with the demo users jdoe (admin) and user1. The masking request tests add their own components and delete them afterwards, and check the emails MailHog catches. They find the app, Keycloak, and MailHog on the stack's ports⁠, SRM_HTTPS_PORT, SRM_KEYCLOAK_PORT and SRM_MAILHOG_PORT, from the environment or, as Compose does, the .env file. To test an app elsewhere, set SRM_URL (default https://localhost:8443/srm), KEYCLOAK_URL (default http://localhost:8081/auth) and MAILHOG_URL (default http://localhost:8025).

⁠Release

1. Bump the version number in the VERSION file and commit and push to GitHub (using Semantic Versioning⁠).
2. The CD⁠ GitHub Action should run automatically invoking:
   • The Create release⁠ GitHub Action to tag the source and create release notes summarizing any pull requests. Edit the release notes to add any missing details. A war file artifact is attached to the release.
   • The Publish docker image⁠ GitHub Action to create a new demo Docker image.
   • The Deploy to JLab⁠ GitHub Action to deploy to the JLab test environment.
   • The Publish user guide⁠ GitHub Action to publish the User Guide⁠ to GitHub Pages, in a folder for the release and in latest/.

⁠Deploy

The deploy to JLab's acctest is handled automatically via the release workflow.

At JLab this app is found at ace.jlab.org/srm⁠ and internally at acctest.acc.jlab.org/srm⁠. However, those servers are proxies for wildfly3.acc.jlab.org and wildflytest3.acc.jlab.org respectively. A deploy script⁠ is provided on each server to automate wget and deploy. Example:

/opt/wildfly/cd/deploy.sh srm v1.2.3

JLab Internal Docs: RHEL9 Wildfly⁠

⁠See Also

• Hot Checkout for 12 GeV at Jefferson Lab⁠, presented at ICALEPCS 2015⁠
• JLab ACE management-app list⁠