Table of Contents

CI/CD Pipeline

Main Pipeline Responsibilities
Pipeline Graph and Parallelism
Branch Suffix Handling
Change Detection and Version Matrix
Payload Build Logic
Firebird Payload Build
Shared Runtime Builds and Registry Cache
Server Build
Admin Build
Client Build
mRomexis Web App Build
Push vs Load
Common CI Troubleshooting

Build is too fast after cache cleanup
latest tag not found
mRomexis build skipped
Payload missing from final image

Deutsch | English

CI/CD Pipeline

The project uses Drone CI to build and publish images to the Gitea container registry.

Main Pipeline Responsibilities

The pipeline builds:

romexis-payload:<version>
romexis-client-payload:<version>
romexis-firebird-payload:latest
romexis-base-jre:11-amd64 / 11-arm64
romexis-gui-runtime:1-amd64 / 1-arm64
romexis-server:<version>-amd64 / -arm64
romexis-admin:<version>-amd64 / -arm64
romexis-client:<version>-amd64 / -arm64
romexis-mromexis-app:<version>-amd64 / -arm64
romexis-migration-service:amd64 / arm64
romexis-control-agent:amd64 / arm64
public multiarch manifests

Pipeline Graph and Parallelism

The build is split into five dependent Drone pipelines:

quality-gate
    |
    v
build-romexis-payload
    |
    +-------------------+
    v                   v
build-romexis-amd64  build-romexis-arm64
    |                   |
    +---------+---------+
              v
create-romexis-manifests

Within each architecture pipeline, independent components can run in parallel according to their dependency graph. Runtime-dependent Server/Admin/Client builds wait only for the runtime they actually consume.

Branch Suffix Handling

For main, image tags are published without a suffix.

For feature branches, the branch name is normalized and appended as an image suffix:

-feature-romexis-admin

This allows feature branch images and manifests to be tested without overwriting main images.

Change Detection and Version Matrix

Drone determines affected components from the branch diff instead of rebuilding the complete image matrix for every commit. Feature branches compare against the merge base of the target/default branch so an earlier change on the same feature branch remains visible to later CI runs.

Typical dependency scopes:

Changed area	Rebuilt components
`romexis-base/**` or server runtime sources	Server runtime, Server
`romexis-gui-runtime/**` or GUI runtime sources	GUI runtime, Admin, Client
`romexis/**`	Server
`romexis-admin/**`	Admin
`romexis-client/**`	Client
`migration-service/**`	Migration Service
`romexis-control-agent/**`	Control Agent
documentation only	no production images

Normal feature branches build only the default Romexis version unless a full matrix build is explicitly requested.

Payload Build Logic

The Windows payload build checks version definitions and both server/admin and Client copy-map changes. Stable payload tags are reused across ordinary feature branches; changed payload generation uses isolated commit-specific CI tags.

Desired behavior:

Change	Behavior
New version added	build only new version
Existing URL changed	force rebuild affected version
Copy map changed	rebuild all payload versions
Extraction script changed	rebuild all payload versions

Firebird Payload Build

The Firebird payload is built after the Windows Romexis payload step.

It uses:

romexis-firebird-payload/romexis-firebird-versions.env

The build pushes:

romexis-firebird-payload:latest

The server image consumes the shared Firebird payload image.

Shared Runtime Builds and Registry Cache

romexis-base-jre and romexis-gui-runtime are built once per architecture when their sources change. BuildKit cache data is stored in separate registry cache scopes and reused through --cache-from / --cache-to.

This prevents expensive package installation, Chilkat extraction and Java/native compilation from being repeated for every Romexis version.

Server Build

The server build combines the selected server runtime, Romexis payload and Firebird payload through explicit BuildKit image contexts:

romexis-server-runtime
romexis-payload
romexis-firebird-payload

When a runtime was rebuilt in the same CI run, its commit-specific staging tag is consumed directly. Otherwise the stable public runtime tag is used. The final Server image is built separately for each architecture.

Admin Build

The Admin build consumes the shared GUI runtime plus the Romexis server/admin payload and builds:

romexis-admin:<version>-amd64
romexis-admin:<version>-arm64
romexis-admin:<version>
romexis-admin:latest

The final image contains the graphical noVNC runtime and Romexis Admin / RomexisConfig files.

Client Build

The Client build consumes romexis-gui-runtime plus romexis-client-payload and publishes versioned amd64/arm64 images. It is independent from the Admin build; an Admin-only source change does not require a Client rebuild.

Published public tags include the version manifest and latest for the configured default version.

mRomexis Web App Build

mRomexis Web App images are built only for Romexis versions where:

version >= 6.5.3

Older versions are skipped because the payload does not contain:

/opt/romexis/broker/mromexis-html.war

Published tags:

romexis-mromexis-app:<version>-amd64
romexis-mromexis-app:<version>-arm64
romexis-mromexis-app:<version>
romexis-mromexis-app:latest

Push vs Load

In CI, architecture builds use --push and write only immutable ci-<commit>-... staging tags. Public version, latest and runtime manifest tags are not modified during the build.

After amd64 and arm64 succeed, the final pipeline creates or replaces public manifests atomically with docker buildx imagetools create. A branch-head guard prevents an older, slower build from publishing over a newer commit. This also keeps existing public manifests pullable while a new build is running.

Common CI Troubleshooting

Build is too fast after cache cleanup

This usually means change detection decided that the component is unaffected, or BuildKit restored most layers from the registry cache. Check the prepare/change-detection output and the component build logs before forcing a rebuild.

latest tag not found

If the server Dockerfile references:

romexis-firebird-payload:latest

then the Firebird payload pipeline must push latest.

mRomexis build skipped

Check the Romexis version. mRomexis Web App is built only for 6.5.3 and newer.

Payload missing from final image

Check the final image:

docker run --rm --entrypoint find   gitea.buchhorster.de/planmeca/romexis-server:<tag>   /opt -maxdepth 3 -type f

Romexis Docker Wiki

English · Deutsch

English

Home

Getting Started

Runtime Services

Build System

Database

Migration

Development

Source Documents

Source README References

Deutsch

Startseite

Erste Schritte

Runtime-Dienste

Build-System

Datenbank

Migration

Entwicklung

Quelldokumente

README-Quellreferenzen

Romexis Docker Project Wiki / Romexis-Docker-Projekt-Wiki

English Home · Deutsche Startseite · English source documents · Deutsche Quelldokumente · Security · Sicherheit

Internal operations and development wiki / Internes Betriebs- und Entwicklungswiki