CI flow [release]

Release flow

The CI flow (release) diagrams depict how FOLIO modules, applications and platform are built and published as official release artifacts. This is essentially the pipeline that takes code that has been prepared (via release branches/tags) and produces the final consumable artifacts for a FOLIO release. In the Eureka-based CI/CD ecosystem, the release CI flow is triggered when a module is ready to be released – typically when a version tag is created in GitHub. Its purpose is to compile the module one last time from the release branch code, run all tests, and deploy the release artifacts (e.g., a non-SNAPSHOT JAR, Docker image, NPM package) to the production artifact repositories. This flow ensures that the code that was tested in the release prep stage is packaged identically for end-users. It fits in the pipeline after the “Release Preparation” stage and culminates in artifacts that can be deployed to production and referenced by the official FOLIO release distribution.

Versions

This flowchart illustrates how version increments propagate through different levels of the FOLIO/Eureka ecosystem—from individual modules (UI or back-end) up to the encompassing application and platform. Each decision (patch, minor, or major) at the module level triggers a corresponding version bump at the application and platform layers. This ensures consistency and compatibility across all components, so that any change in underlying modules is accurately reflected in the application’s and, ultimately, the platform’s version.

Modules flow

Applications flow

Scan view

This diagram shows an automated “scan” process that periodically checks for newer module versions in the app-* repository’s release branches (current and previous release). If updated modules are found, the workflow either creates a new pull request or updates an existing one with the latest versions, increments the application’s own version, and commits those changes. This ensures the application stays current by automatically detecting and applying module updates.

On the PR update view

This diagram outlines the automated Pull Request update process for a FOLIO/Eureka application. When a pull request is updated, a GitHub workflow fetches the platform descriptor and required application data, updates the application configuration (replacing the application’s own descriptor), and then runs a validation step. If the new configuration passes validation, the updated application descriptor is committed to the pull request branch, and a success status is posted (along with Slack notifications). If validation fails, the process reports the error status and notifies the team, ensuring all changes are verified before merging.

On the PR merge view

This diagram shows the final step in merging a pull request for the app-* repository’s release branch. Upon approval and merge, a GitHub workflow reads the updated application descriptor, publishes it to an external registry (e.g., S3, GitHub, or another repository), removes local references, commits the changes, and notifies the team (via Slack). The workflow then merges the PR and tags the final merge commit with the new version. This ensures all validated updates are recognized as an official version and properly recorded.

General view

This diagram provides a high-level view of the three automated processes that keep an app-* repository in sync and properly versioned:

1. Scan Flow: Periodically checks for updated module versions or other changes. If it finds any, it creates (or updates) a pull request with the new configuration and increments the application version as needed.

2. Pull Request Update Flow: Whenever a pull request changes, a GitHub workflow fetches the platform descriptor, updates the application descriptor, and validates the resulting configuration. If validation passes, it commits the updated descriptor to the PR branch and notifies the team.

3. Pull Request Merge Flow: After approval, the PR is merged into the release branch. The workflow then publishes the finalized descriptor to an external registry, removes local references, and tags the merge commit with the new version—ensuring the application remains consistently versioned and ready for deployment.

Platform flow

Scan view

This diagram shows the automated scanning process that periodically checks the platform-lsp repository for new versions of eureka modules or applications. The workflow retrieves the current platform descriptor, compares it against the latest available versions, and determines whether updates are needed. If new versions are found, it either updates an existing pull request or creates a new one to the release branch. The updated platform descriptor is then committed, ensuring the platform stays current with all underlying components.

On the PR update view

This diagram shows the automated process that runs whenever a pull request in the platform-lsp repository is updated. The workflow begins by retrieving the current platform descriptor and referenced applications. It then updates package.json, runs a validation step (including build and tests), and checks if everything passes. On success, it commits the updated platform descriptor back to the pull request branch and notifies the Release Manager (and Slack). If validation fails, the workflow flags the pull request and alerts the team, ensuring any configuration issues are caught before merging.

On the PR merge view

This diagram shows the final step of merging a pull request in the platform-lsp repository. After the PR is reviewed and approved, notifies the team (e.g., via Slack). This confirms the updated platform descriptor as the official release, ensuring all changes are properly recorded and communicated.

General view

This diagram provides a high-level view of the three automated processes that keep the platform-lsp repository aligned with the latest module and application versions:

1. Scan Flow: Periodically checks for new versions by retrieving the current platform descriptor and comparing it to the latest available modules/applications. If updates are needed, it either updates an existing pull request or creates a new one with the revised descriptor.

2. Pull Request Update Flow: Whenever the pull request is updated, the workflow validates the updated descriptor (including build and tests). If validation succeeds, it commits the changes back to the pull request branch and notifies the team. Any validation failure flags the pull request and alerts maintainers for further review.

3. Pull Request Merge Flow: Once approved, the pull request is merged into the release branch. The workflow notifies the team, confirming the updated platform descriptor as an official release.