CI flow [snapshot]

Snapshot flow

These diagrams illustrate the snapshot CI flow, which handles continuous integration of ongoing development (snapshot builds). It shows how a FOLIO module (for example, a back-end module like mod-a or an edge API module), the FOLIO application, and the FOLIO platform are continuously built, tested, and published whenever code changes are pushed to the main development branch. In the Eureka CI/CD ecosystem, this snapshot flow is the backbone of daily development integration – ensuring that every commit triggers an automated build and that up-to-date “snapshot” artifacts are available for testing. It feeds into FOLIO’s snapshot environments (the continuously rebuilt test deployments) and serves as the first step before any release-specific process.

Versions and versioning flow view

This diagram shows how different components (JS modules, Java modules, the overall application, and the platform) move from snapshot (master) versions to updated builds. Each step increments the “Build ID” for the module, then the application, then the platform. Versioning follows a standard pattern (x.y.z-SNAPSHOTk or similar), with x as Major, y as Minor, z as Patch, and k as the Build ID.

Modules flow

Java-based modules flow view

This flow illustrates how a FOLIO Java-based module (e.g., mod-a or edge-a) is continuously built, tested, and published whenever code changes are pushed to GitHub. A Jenkins job is triggered, which:

1. Builds & Tests the Source Code using Maven (or a similar tool).

2. Builds a Docker Image for the module.

3. Generates a Module Descriptor describing the module’s capabilities.

4. Publishes Artifacts to the following destinations:

• Maven repository (for snapshot artifacts)

• Docker Hub (for the container image)

• folio-registry (for the module descriptor)

This ensures each code commit is validated, containerized, and registered, making the module readily available for deployment and integration within the FOLIO ecosystem.

UI/Stripes modules flow view

This flow illustrates how a FOLIO UI/Stripes module (e.g., ui-a) is continuously built, tested, and published whenever code changes are pushed to GitHub. Typically, a GitHub Actions workflow (or a Jenkins job) is triggered, which:

1. Builds & Tests the Source Code using Node.js/Yarn (or npm) to ensure quality and functionality.

2. Generates a Module Descriptor describing the UI module’s capabilities and dependencies.

3. Publishes Artifacts to the following destinations:

• NPM repository (e.g., npm-folio) for snapshot or release packages.

• folio-registry to register the module descriptor.

This ensures each code commit is validated, packaged, and registered, making the UI module readily available for deployment and integration within the Stripes-based FOLIO ecosystem.

Applications flow view

This diagram illustrates how each app-* repository continuously updates its snapshot branch with the latest module changes. The process starts by detecting new versions. It then fetches the relevant application descriptors, replaces the local snapshot configuration, and runs a build/test cycle to validate everything. If the validation succeeds, the snapshot branch is updated and remains in sync with ongoing development. If any step fails, the process halts and notifies the team, ensuring that unverified changes do not enter the snapshot branch.

Platform flow

This diagram shows how the platform-lsp snapshot branch is continuously updated with the latest module and application versions. The process begins by detecting new versions, then proceeds to update the snapshot configuration and run a build/test cycle. If the update passes validation, the snapshot branch is refreshed and the updated application can be deployed. If validation fails at any point, the process halts and notifies the team, ensuring issues are flagged early while keeping the snapshot branch as current as possible.

Complete flow