Continuous Integration and Continuous Delivery¶
OmegaT uses two CI/CD platforms:
Azure Pipelines — the primary platform, handling build, test, and publishing of Windows packages and documentation.
GitHub Actions — handles Linux package builds, daily quality checks, and supplementary publishing.
The pipeline configuration files are located under ci/azure-pipelines/ and .github/workflows/.
Azure Pipelines¶
The main pipeline definition is azure-pipelines.yml at the project root.
It is triggered on pushes and pull requests targeting master and releases/* branches,
as well as on a weekly schedule (every Saturday at 12:00 UTC).
The pipeline is structured into three stages:
Stage 1: TestAndDocCI¶
Runs on every push and pull request (but not on scheduled or manual runs, and not on release tags).
A CheckChanges job first inspects which files have changed since the previous commit (or since
master for pull requests). Based on the result, downstream jobs are conditionally executed:
BuildDocument — runs only when documentation files under
src_docs/or tip-of-the-day files have changed.testOnLinux / testOnWindows / testOnMac — run only when non-documentation source files have changed.
Stage 2: Weekly¶
Runs on a scheduled Saturday build or on a manual trigger.
This stage runs the following jobs in parallel before publishing:
CheckForWeekly — runs
check_steps.yml, which executes the Gradlechecktask. This is a comprehensive quality gate that includes unit tests, style checks, and other verifications.IntegrationTestForWeekly — runs
integ_test_steps.yml, which launches Docker Compose-based integration tests (GIT type, with a 600 second duration limit).WeeklyBuild — builds Windows and macOS distribution packages and documentation. Uses
build_steps.ymlandbuild_doc_steps.yml(see below).
WeeklyPublish depends on all three jobs above succeeding, then downloads the pipeline
artifacts and uploads them to the SourceForge file release server via publish_weekly.yml.
Stage 3: Release¶
Triggered only when a version tag (matching refs/tags/v*) is pushed.
CheckForRelease — same as
CheckForWeekly: runs the full Gradlechecktask.ReleaseBuild — depends on
CheckForReleasepassing. Builds all distribution packages and documentation usingbuild_steps.ymlandbuild_doc_steps.yml.ReleasePublish — downloads the built artifacts and uploads them to the SourceForge release directory via
publish_release.yml.
Azure Pipeline Sub-tasks¶
The reusable step templates live under ci/azure-pipelines/:
File |
Purpose |
|---|---|
|
Downloads bundled JREs, builds Windows and macOS packages ( |
|
Builds the HTML manuals using the Gradle |
|
Runs the Gradle |
|
Runs and tears down Docker Compose-based integration tests. Accepts |
|
Uploads distribution packages to |
|
Uploads distribution packages, HTML manuals, and Javadoc to versioned release directories on SourceForge, using SFTP via |
|
Runs the standard test suite on a given platform (Linux, Windows, macOS) using JDK 17. |
GitHub Actions¶
Linux Package Build and Publish (publish-linux.yml)¶
This workflow builds Linux distribution packages and publishes them to SourceForge.
It is triggered by:
A version tag push (
v*) — publishes as a release.A weekly schedule (every Saturday at 13:18 UTC) — publishes as a weekly snapshot.
A manual
workflow_dispatch— lets you choosereleaseorweeklyexplicitly.
The build job uses a matrix strategy to build on two architectures in parallel:
Architecture |
Runner |
Gradle tasks |
|---|---|---|
|
|
|
|
|
|
Each build step:
Downloads the appropriate Temurin JRE 17 for its architecture into a local
asset/directory.Runs the Gradle tasks using
jpackage-based tasks defined inorg.omegat.linux-conventions.gradleandorg.omegat.jpkg-conventions.gradle.Uploads the distribution files as GitHub Actions artifacts.
The publish job then:
Downloads the artifacts from both architectures.
Determines whether to publish to the
Weeklyfolder or to a versioned release folder on SourceForge, based on the trigger event.Uploads via
lftpover SFTP using an SSH key stored as a GitHub Actions secret.
Note: Both architectures must succeed (
fail-fast: falseis set, butpublishrequires both build jobs).
Daily Quality Checks on GitHub Actions¶
The following workflows run on every push to master / releases/* and on every pull request,
providing continuous quality feedback. Most workflows skip ci/, src_docs/, and *.md changes
to avoid unnecessary runs on non-code changes.
Workflow file |
Name |
What it checks |
|---|---|---|
|
Acceptance Tests |
Runs the UI acceptance test suite under a virtual framebuffer ( |
|
Run checkstyle |
Runs |
|
Quality checks |
Runs the full Gradle |
|
Check manuals build |
Builds the HTML manuals with |
|
Run PMD |
Runs |
|
Qodana |
Runs a nightly JetBrains Qodana static analysis scan and uploads results to the Qodana cloud. |
|
Run Semgrep |
Runs Semgrep SAST analysis on every pull request and on pushes to |
|
Source Distribution Test |
Builds the source distribution with |
|
Run SpotBugs |
Runs |
Notes on specific checks¶
Acceptance Tests require a display server; the workflow installs
xvfband related X11 libraries before running.Qodana runs nightly on a schedule (daily at 21:03 UTC) rather than on every push, due to its longer execution time. It uses a baseline file (
qodana.sarif.json) to suppress known issues.Source Distribution Test is particularly important for catching missing dependency declarations: it installs the source distribution to a clean directory and attempts to build it independently, failing fast if any transitive dependency is absent from the declared dependency list.
Semgrep skips pull requests from
dependabot[bot]to avoid permission issues with the Semgrep token.
Secrets and Credentials¶
The publish pipelines require the following secrets to be configured:
Secret |
Platform |
Purpose |
|---|---|---|
|
Azure / GitHub |
SourceForge SFTP username |
|
Azure / GitHub |
Passphrase for the SSH private key |
|
Azure / GitHub |
SSH private key for SourceForge SFTP access |
|
GitHub |
Authentication token for uploading Qodana results |
|
GitHub |
Authentication token for the Semgrep cloud app |
CI File Locations Summary¶
azure-pipelines.yml # Root pipeline definition (Azure)
ci/
azure-pipelines/
build_steps.yml # Windows/macOS/source distribution build
build_doc_steps.yml # Manual HTML build
check_steps.yml # Gradle check + test result publishing
integ_test_steps.yml # Docker Compose integration tests
publish_weekly.yml # Upload to SourceForge Weekly
publish_release.yml # Upload to SourceForge release folder
test_java17_steps.yml # Cross-platform unit test run
.github/
workflows/
acceptance-master.yml # UI acceptance tests
checkstyle-annotate.yml # Checkstyle
gradle-check-master.yml # Gradle check + clean tree verification
manuals-builds-master.yml # Manuals HTML build check
pmd-annotate.yml # PMD static analysis
publish-linux.yml # Linux package build + SourceForge publish
qodana-code-quality.yml # Nightly Qodana scan
semgrep.yml # Semgrep SAST
source-distribution-test.yml # Source distribution build + dependency check
spotbugs-annotate.yml # SpotBugs static analysis