RANCHER-2537. R1-2025 (Sunflower) Environment Deployment from the related branch

Overview

This spike investigates the feasibility and requirements for creating Sunflower-like environments (R1-2025 release) that can be updated from pre-release branches, with and without BF (Bugfest) dataset support. The investigation revealed critical blockers and process improvements needed for sustainable daily builds.

Problem Statement

The FOLIO project needs to establish a process for building R1-2025 (Sunflower) release environments on a daily basis for testing and validation purposes. These environments must:

• Use release branch R1-2025

• Support both empty and BF dataset deployments

• Be maintainable through automated daily builds

• Work with the Eureka platform architecture

Investigation Approach

Test Environments Created

1. eclutches (folio-edev cluster)

   • Empty dataset deployment

   • R1-2025 release branches

   • Eureka platform with consortia support

2. sunflower-testing (folio-etesting cluster)

   • BF dataset deployment (sprint-testing-prep-8-18-2025)

   • RDS PostgreSQL

   • Full application suite

Modified Components

• Jenkins shared library (RANCHER-2537-test branch)

• Application repositories (forked for fixes)

• Platform-complete configurations

• UI build configurations

Key Findings

1. Critical Blockers

Interface Integrity Validation Failure (Backport is not required. Sunflower release notes should be updated with notes that app-platform-complete and app-platform-minimal should installed together with app-acquisitions application)

• Issue: Module descriptors in R1-2025 release branches lack the optional interface declarations present in snapshot versions

• Impact: Deployment fails unless VALIDATION_INTERFACE_INTEGRITY_ENABLED is disabled

• Required Action: Development teams must update module descriptors in release branches

• Related tp: New app-acquisitions application was introduced and several modules were expelled from app-platform-complete.

Application Dependency Mismatches (

Action items:

• Issues Found:

  • app-linked-data: Incorrect dependency version (^1.0.0-SNAPSHOT vs ^2.1.0-SNAPSHOT)

  • app-erm-usage: Missing caret notation for version ranges

  • app-edge-complete: Contains edge-fqm and edge-orders module belonging to another application

• Impact: Deployment failures due to version conflicts

• Required Action: Review and correct all application templates in master branches

Lack of Eureka CI in Production

• Issue: No automated way to update application modules without Eureka CI

• Impact: Manual intervention required for all module updates

• Required Action: Move Eureka CI to the production stage first

2. Technical Discoveries

Platform-specific Module Requirements

• Inn-reach modules (mod-inn-reach, edge-inn-reach) are Eureka-specific in R1-2025

• UI modules have different configurations between the Eureka and OKAPI platforms

Pipeline Modifications Required

• folioUI.groovy: Needs to be changed to specify the proper release version of the UI modules in the package.json

• folioNamespaceCreateEureka.groovy: Must properly pass isRelease parameter and take the release description for consortia modules

• Constants.groovy: Update application composition in Constants.groovy to use correct branches for releases (Potentially WILL NOT DO IT, see P.3 Eureka CI)

3. Successful Workarounds (Not Production-Ready)

• Disabled interface integrity validation globally

• Created forked application repositories with manual fixes

• Used different application compositions for snapshot and release deployments

• Hard-coded UI module versions for specific releases

Solution Design

1. Backport Module Descriptor Changes to the Release Versions.

   • Backport changes from the snapshot module versions to the release versions within the scope of the required/optional descriptor dependencies. Related to the app-platform-complete vs app-acquisitions modules.

   • Ensure consistency between snapshot and release versions

2. Clean Application Repositories

   • Correct dependency versions in app-* repository master branches

   • Remove modules that belong to other applications

   • Standardize version notation (use caret ^ for ranges)

3. Deploy Eureka CI

   • Move Eureka CI to the production stage

   • Enable automated application module updates

4. Update Pipeline Components

   • Modify folioUI.groovy for dynamic release version handling

   • Fix folioNamespaceCreateEureka.groovy for proper parameter passing

   • Consider permanent changes to Constants.groovy for release support

Implementation Status

Completed

✅ Successfully deployed R1-2025 environments (with workarounds)
✅ Identified all critical blockers
✅ Created reusable Jenkins API automation script
✅ Fixed UI configuration issues
✅ Added missing Eureka-specific modules
✅ sunflower-testing environment deployment with BF dataset

Pending

❌ Module descriptor fixes in release modules
❌ Application repository cleanup
❌ Eureka CI production deployment
❌ Pipeline permanent modifications

Risks and Mitigation

Conclusion

The spike demonstrates that R1-2025 environments can be deployed, but several critical issues prevent reliable daily builds:

1. Interface integrity validation must be fixed at the module level

2. Application repositories need consistency cleanup

3. Eureka CI is essential for sustainable automation

4. (Optional) mgr-application Semver validator (currently fixed in the snapshot module version and isn’t fixed in the release version).

Without addressing these blockers, daily R1-2025 environment builds will require manual intervention and workarounds unsuitable for production use.

References

• RANCHER-2537 Jira Ticket

• Modified Pipeline Branch

• Test Environments:

  • eclutches-diku

  • eclutches-consortium

  • sunflower-testing