sls/hla_framework_bd
0
1
Fork 0
Code Issues 19 Pull Requests 3 Actions Packages Projects 1 Releases Wiki Activity

Merge branch 'main' of gitea.psi.ch:sls/hla_framework_bd
Deploy / deploy (push) Successful in 9s
Details

Browse Source
This commit is contained in:
Benjamin Labrecque
2026-08-28 14:47:58 +02:00
parent bc22b09a62 83f2e48992
commit 13c64e771a
4 changed files with 78 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/developer/cicd_runner.md
+13 -3
View File
@@ -9,6 +9,12 @@
- Runs the runner itself, and therefore everything else: the deployments
to `/sls/bd/hla/<env>/` and the `ioc ...` commands
## Install the runner
```
sudo dnf install act-runner
```
## Setup
Resources:
@@ -21,9 +27,12 @@ Register the runner: (by default the name is the machine name `sls-vserv-bd-hla0
sudo su svcusr-sls2hla
mkdir ~/gitea-runner
cd ~/gitea-runner
/usr/local/bin/act_runner register --instance https://gitea.psi.ch/ --labels hla-dev --token <token> --no-interactive
/usr/local/bin/act_runner generate-config | sudo tee /etc/act_runner/config.yaml > /dev/null
/usr/local/bin/act_runner --config /etc/act_runner/config.yaml register --instance https://gitea.psi.ch/ --labels <labels> --token <token> --no-interactive
```
where we used `hla-dev` or `hla-prod` for the labels.
Note, if you use a systemd service with a config file as in the example below,
the labels will be read from that file.
@@ -37,7 +46,8 @@ chmod 755 /sls/bd/hla
...
```
Install Node -- required for actions like repo checkout
Install Node -- required for actions like repo checkout (TODO: was not done on `prod` runner `sls-vserv-bd-hla01` yet --> no internet access)
```
mkdir ~/.local/bin
@@ -140,7 +150,7 @@ Configure the runner labels: (edit `/etc/act_runner/config.yaml`)
```
runner:
labels:
- "hla-dev"
- "hla-dev" # or "hla-prod"
```
Enable and restart:
docs/user/add-new-service.md
+30 -6
View File
@@ -23,6 +23,24 @@ agebd --help
agebd service add --help
```
**This command has side effects you should know about before running it.** It requires a
clean working tree, then it:
1. Assigns the service the next free IOC port and registers it in
[`config/services_registry.yml`](https://gitea.psi.ch/sls/hla_framework_bd/src/branch/main/config/services_registry.yml).
2. Adds the service to `AGEBD-CPCL-MASTER`'s IOC pattern file, so it gets the standard
ALH lifecycle PVs (`AGEBD-ALH$(SUFFIX):$(SERVICE)-*`) and appears in the `ServiceManager`
GUI screen.
3. Appends a row to [`iocs_overview.md`](ioc/iocs_overview.md).
4. Creates a new branch **`feature/add-service-<name>`**, scaffolds the new service's files
from the templates, and **pushes the branch automatically** — you don't run `git push`
yourself.
Pushing that branch triggers the `Add new service` Gitea Actions workflow
(`.gitea/workflows/add-new-service.yml`), which deploys `master`, installs/restarts its IOC,
deploys your new service, and installs/starts its own IOC — all in `dev`. Check the Actions
tab for that run to confirm it succeeded before doing anything else with the new service.
## Environments
The services are deployed to 2 environments:
@@ -42,17 +60,23 @@ We distinguish between
#### PVs - Service Specific
You create them, see (# TODO: docs...)
These are defined as EPICS records in your service's own `services/<name>/current/ioc/*.template`
file, instantiated by `services/<name>/current/ioc/AGEBD-CPCL-<NAME>_main.subs`.
`prod` and `dev` PVs automatically get created.
`prod` and `dev` PVs automatically get created: at deploy time, `{{ agebd_env_suffix_upper }}`/
`{{ agebd_env_suffix_lower }}` placeholders in those files are substituted with `-DEV`/`-dev`
in `dev`, or left empty in `prod` (see `.gitea/scripts/deploy-service.sh`).
In your code, you only use the `prod` name of a PV. The framework will automatically use the
`dev` name/PV when a service runs in the `dev` environment.
In your code, you only use the `prod` name of a PV, e.g. `PV("AGEBD-MYSERVICE:MYPVNAME")`.
The `PVLink`/`DevPVLink` framework (`packages/agebd/src/agebd/pv.py`) automatically appends
`-DEV` when the service runs in `dev` — but **only** for PVs belonging to your own service,
plus `AGEBD-ALH`/`AGEBD-MASTER`. See "External" below for PVs owned by another service.
#### PVs - External
The framework will use the same PV in `prod` and `dev`, i.e. there is no `dev` PV.
However, in `dev` you can only read from the PV, whereas in `prod` you can also write to it.
PVs owned by another service (including another AGEBD service, e.g. `AGEBD-PARAMS:...` used
from a different service) or by real accelerator hardware (e.g. `ARS01-MOCT-...`) are used
verbatim — no `-DEV` suffix is ever added, even in `dev`.
#### PVs - Examples
docs/user/gui.md
+14 -7
View File
@@ -2,22 +2,29 @@
## Launch
```
cd <repo-root>
```
In `prod`:
`ssh sls-vserv-bd-hla01`
```
./bin/sls_hla_launch_gui.sh qt/A_BD_InjectionGuard.ui
cd /sls/bd/hla/prod/qt
../bin/sls_hla_launch_gui.sh A_BD_ServiceManager.ui
```
In `dev`:
`ssh sls-vserv-bd-hla01-dev`
```
./bin/sls_hla_launch_gui.sh qt/A_BD_InjectionGuard.ui dev
cd /sls/bd/hla/dev/qt
../bin/sls_hla_launch_gui.sh A_BD_ServiceManager.ui "dev"
```
Any extra arguments are passed straight through to `caqtdm`, e.g. to set a macro:
```
./bin/sls_hla_launch_gui.sh qt/A_BD_Tune.ui dev -macro "OTHER_ENV_VAR=HEYHEY"
../bin/sls_hla_launch_gui.sh A_BD_ServiceManager.ui "dev" -macro "OTHER_ENV_VAR=HEYHEY"
```
**Note:** launching straight from a git checkout, as above, uses the raw `.ui` files as
committed - including the literal `{{ agebd_env_suffix_upper }}`/`{{ agebd_env_suffix_lower }}`
placeholders in their PV names. Those only get substituted with `-DEV`/`-dev` (or emptied out,
in `prod`) at deploy time, by `.gitea/workflows/deploy.yml`'s `"Qt - deploy"` step, on the
*deployed* copy at `/sls/bd/hla/<env>/qt/`. If widgets show up blank or unresponsive, check
whether you're accidentally pointing at the raw checkout instead of the deployed `.ui` file.
docs/user/ioc/iocs_overview.md
+21 -14
View File
@@ -1,11 +1,10 @@
# Overview of IOCs for Beam Dynamics
The ports are configured in the [service registry](../../../config/services_registry.yml)
The ports are configured in the [service registry](https://gitea.psi.ch/sls/hla_framework_bd/src/branch/main/config/services_registry.yml)
| IOC NAME | Description |
|---|---|
| AGEBD-CPCL-MASTER | IOC providing PVs for the service master application and IOC enabling to monitor the health status of BD High Level Application Services with the alarm handler ALH |
| AGEBD-CPCL-ALH | IOC enabling to monitor the health status of BD High Level Application Services with the alarm handler ALH |
| AGEBD-CPCL-MASTER | IOC providing PVs for the service master application, and monitoring the health status of BD High Level Application Services via the alarm handler ALH. ALH is not a separate IOC - its `AGEBD-ALH$(SUFFIX):$(SERVICE)-*` PVs are defined directly in `MASTER.template`, one row per registered service. |
| AGEBD-CPCL-TUNE | IOC providing PVs for the tune measurement |
| AGEBD-CPCL-SCRUBBING | IOC providing PVs for the vacuum scrubbing service |
| AGEBD-CPCL-NTURNS | IOC providing PVs for the DBPM3 stage0 and stage1 nr. of turns calculation service |
@@ -15,15 +14,23 @@ The ports are configured in the [service registry](../../../config/services_regi
| AGEBD-CPCL-TUNEBUMP | IOC providing PVs for the tune bump service application |
| AGEBD-CPCL-PLOTS | IOC providing Buffers of PVs for plots |
| AGEBD-CPCL-ORBITBUMP | IOC providing PVs for orbit bumps for the beamlines |
| AGEBD-CPCL-TAUBPM | IOC providing PVs for the lifetime measurement |
| AGEBD-CPCL-TAUBPM | IOC providing PVs for the lifetime measurement (BPM based) |
| AGEBD-CPCL-TAUPCT | IOC providing PVs for PCT based lifetime measurement |
| AGEBD-CPCL-TOPUPTOOL | IOC providing PVs for the top up tool |
| AGEBD-CPCL-TUNEFBX | IOC providing PVs for the top up tool |
# TODO:
| IOC NAME | Description |
|---|---|
| AGEBD-CPCL-PARAMS | IOC providing PVs for machine parameters |
| AGEBD-CPCL-PARAMS | IOC providing PVs for PCT base lifetime measurement |
| AGEBD-CPCL-SHIFTTOOL | |
| AGEBD-CPCL-DBPM3CURR | |
| AGEBD-CPCL-DBPM3 | IOC providing PVs for the DBPM3 stage2 average current calculation service |
| AGEBD-CPCL-TUNEFBX | IOC providing PVs for the horizontal tune feedback |
| AGEBD-CPCL-TUNEFBY | IOC providing PVs for the vertical tune feedback |
| AGEBD-CPCL-PARAMS | IOC providing PVs for machine parameters (e.g. injection state, lifetime, current limit) |
| AGEBD-CPCL-DBPM3CURR | IOC providing PVs for the DBPM3 stage2 average current calculation service |
| AGEBD-CPCL-SHIFTTOOL | IOC providing PVs for the shift log / handover tool |
| AGEBD-CPCL-BEAMTRANSFERCHECKS | IOC providing PVs for beam transfer checks |
| AGEBD-CPCL-OPTICSFF-X02S | IOC providing PVs for optics feed-forward on the I-TOMCAT beamline |
| AGEBD-CPCL-OPTICSFF-X03M | IOC providing PVs for optics feed-forward on the ADRESS beamline |
| AGEBD-CPCL-OPTICSFF-X04S | IOC providing PVs for optics feed-forward on the ADDAMS beamline |
| AGEBD-CPCL-OPTICSFF-X05L | IOC providing PVs for optics feed-forward on the QUEST beamline |
| AGEBD-CPCL-OPTICSFF-X06S | IOC providing PVs for optics feed-forward on the PXI beamline |
| AGEBD-CPCL-OPTICSFF-X07M | IOC providing PVs for optics feed-forward on the PHOENIX/XTREME beamline |
| AGEBD-CPCL-OPTICSFF-X08S | IOC providing PVs for optics feed-forward on the MicroXAS beamline |
| AGEBD-CPCL-OPTICSFF-X09L | IOC providing PVs for optics feed-forward on the OPERA beamline |
| AGEBD-CPCL-OPTICSFF-X10S | IOC providing PVs for optics feed-forward on the PXII beamline |
| AGEBD-CPCL-OPTICSFF-X11M | IOC providing PVs for optics feed-forward on the SIM beamline |
| AGEBD-CPCL-OPTICSFF-X12S | IOC providing PVs for optics feed-forward on the cSAXS beamline |