[FOLIO-1577] Automated builds for FOLIO 'release' Created: 12/Oct/18  Updated: 04/Apr/19  Resolved: 04/Apr/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Umbrella Priority: P2
Reporter: John Malconian Assignee: John Malconian
Resolution: Done Votes: 0
Labels: ci, platform-backlog, q1-2019, sprint49, sprint50, sprint51, sprint52, sprint53, sprint54
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks FOLIO-1596 enable platform builds for all ui-* m... Closed
is blocked by FOLIO-1519 Automatic loading of sample and refer... Closed
is blocked by FOLIO-1738 PR build pipeline for platform-core r... Closed
is blocked by FOLIO-1739 PR build pipeline for platform-comple... Closed
is blocked by FOLIO-1740 tweak renovate configuration for plat... Closed
is blocked by FOLIO-1742 build and deploy platform-core/master... Closed
is blocked by OKAPI-683 Allow checking if uploaded Module Des... Closed
Duplicate
is duplicated by FOLIO-1043 integrate ui-testing with PR Closed
Relates
relates to FOLIO-1614 SPIKE: decide on frequency of releases Closed
relates to FOLIO-1631 add a "released dependency check" to ... Closed
relates to OKAPI-684 better report dependency issues Closed
relates to FOLIO-1597 Add module dependency resolution qual... Closed
relates to FOLIO-1602 Enable coverage reporting on UI night... Closed
relates to FOLIO-1755 verify dependency resolution checking Closed
relates to UXPROD-1155 Q4 release plan and management Closed
relates to UXPROD-1428 Q1 2019 release plan and management Closed
Sprint:
Development Team: Core: Platform

 Description   

Summary

Continuously integrate and test new releases of both front-end and server-side components into
a current and stable FOLIO instance that is accessible to POs, developers, and manual testers.

Description

Implement automated build pipelines for stripes platforms (platform-core and platform-complete)
designed to integrate newly released modules into a stable FOLIO instance based solely on
"released" versions of artifacts. PRs will be submitted in order add and test newly released
stripes and UI modules into the on-going, stable release branch (master) of each platform's git
repository. The PRs can either be manually created or generated automatically by an NPM dependency
bot app that integrates with Github like Renovate or Greenhopper. These bots check for NPM
dependency updates for specified NPM packages and repositories and automatally initiate
pull requests to merge updated dependencies. Each PR will first trigger a build of the stripes
platform, and, if successful will then attempt to build a FOLIO full stack by utlizing Okapi's
"install" endpoint to resolve required interface dependencies provided by released server-side
modules. If the build is successful, the UI integration test suite is run against the built
FOLIO instance. If all tests pass, the PR can be then be merged to the stable release branch
of the platform which will, in turn, can be used to build a publically accessible current and
stable instance of FOLIO that can be used for additional testing/demos, etc.

The PR test process includes the following quality gates:

  • Successful webpack build of the stripes platform. If the stripes platform cannot be built,
    then the PR will fail.
  • Successful interface dependency resolution between frontend and backend modules (releases only).
    If the new frontend module requires an interface that cannot be resolved by a released backend
    module, then PR will fail. This will ensure that frontend and backend module releases are
    coordinated.
  • Successful build of FOLIO instance to ensure installation processes are configured and working
    as expected and tenent initialization is successful.
  • Ensure passing UI integration tests to indicate either successful integration of the new module
    into the platform or to ensure tests are kept and current and compatible with new functionality.

Tools/Platforms

Each platform git repository will be integated with a Jenkins pipeline responsible for coordinating
builds and testing using additional tools like folio-ansible and AWS. Each platform will also
be configured with a NPM dependency bot like Renovate to provide updates to the platform and
initiate PRs.

Additional Outputs

  • A yarn.lock file representing a stable set of fixed NPM dependencies committed to the platform's
    stable, release branch.
  • install.json files committed to each platform's stable, release branch that can be used to
    build a FOLIO system from the most recent set of released and stable module.

Prerequisites/Considerations

  • Front-end and backend module releases must occur on a regular, continuous basis in order
    for this process to work. Integration is more successful at regular, steady intervals (see FOLIO-1614 Closed )
  • An existing set of released compatible modules must be exist in order to build initial system
    (initial set to be based on Q4 release).
  • AWS resource utilization. We need to design a system that is cognizant of AWS resource
    utilization. Each PR will utilize an AWS EC2 instance and attached storage to build a
    FOLIO stack. Additionally, the process could be simplified to initialize a new tenant
    for each PR on an existing okapi cluster as long as larger number of released backend modules
    can be distributed across a cluster. Such a setup would most likely require additional
    orchestration tools, however. These ideas can be explored at a latter stage.
  • Determine how new backend module releases that are not explicitly required by frontend
    modules will be integrated into stable, release system.
  • Some Renovate initiated changes will fail, e.g consider the following scenario:
    "PR is issued to include new ui-users that depends on mod-circulation v2 but ui-checkin still depends on v1" in this and similar cases, a manual intervention will be required and a single PR that updates all ui- versions and a version of a shared dependency will be needed

Definition of Done

  • Determine if prerequisites and considerations described above have been initially addressed.
  • Implement the process as described above and produce initial folio-release instances
    for platform-core and platform-complete.


 Comments   
Comment by Jakub Skoczen [ 24/Oct/18 ]

John Malconian any relation to what we are discussing as 1. on UXPROD-1827 Closed ?

Comment by John Malconian [ 25/Oct/18 ]

This is blocked due to the fact that we have not yet established a regular release interval for modules. It is currently not possible to build a working folio instance based on the next-release branch of either platform-core or platform-complete because

1. The requisite backend modules required by frontend modules have not been released. The 'next-release' platform needs to be based solely on released frontend and backend modules. It is not sufficient to use snapshot versions of backend modules because sample data needs to be pinned to tagged releases.

2. The current configuration of frontend modules have conflicting interface dependency requirements.

Example:

jenkins@8e6da5a15783:~/platform-core$ curl -X POST -d @stripes-install.json -H 'Content-Type: application/json' "http://next-release-core.aws.indexdata.com:9130/_/proxy/tenants/test1/install?simulate=true&preRelease=false"
Incompatible version for module mod-inventory-10.0.0 interface item-storage. Need 6.0. Have 5.3
Comment by Jakub Skoczen [ 30/Oct/18 ]

John Malconian keeping this aligned would require keeping track of all module releases and pushing fro a release where one is missing. This would be the same as we do with Q-releases where we coordinate a spreadsheet of all module versions. Do you want to do something like that here or did you have something else in mind?

Comment by John Malconian [ 30/Oct/18 ]

I created a Q4 release spreadsheet similar to the Q3 release spreadsheet. The link is included in the 'release-q4-2018' Slack channel.

Comment by John Malconian [ 31/Oct/18 ]

Specifically, we need updated releases for mod-inv, mod-inv-storage, mod-circ, mod-circ-storage, and mod-users-bl (service-points).

Comment by Anton Emelianov (Inactive) [ 06/Nov/18 ]

Reached out to Kurt Nordstrom and Marc Johnson via email to help with the latest releases of the above modules

Comment by Jakub Skoczen [ 07/Nov/18 ]

John Malconian Anton Emelianov Guys, I'd like to understand why we need those modules released – is it because (released) ui-modules require new versions of their backend dependencies? Is there a problem creating the Q4/next-release environment with the set of last released modules?

We will cover release planning for backend modules in the coming days/early next week and come up with a schedule for November. I'd like this schedule to be focused on delivering support for planned features though so I'd like to know if there are other factors that would prompt certain releases.

Comment by Marc Johnson [ 07/Nov/18 ]

Jakub Skoczen My understanding is there have already been new features added to some of the backend modules (mod-circulation, mod-circulation-storage, mod-inventory, mod-inventory-storage and mod-users-bl) that have changed the interface versions.

These new versions have become dependencies of the current versions of the UI modules, and so it is not possible to build the first iteration of the Q4 without formal releases of these modules, as they currently stand.

My intention was to attempt to make those releases today.

Mod-inventory-storage is a little challenging as we do not want to release the head of master at this point. My intention here was to branch from a previous revision, release from there and then manually update master with the news and a new implementation version.

I am aware this isn't ideal, and I would've preferred not to commit anything to master whilst we are working on the current issues. I'd like Niels Erik Nielsen Adam Dickmeiss and Julian Ladisch thoughts on whether this sounds like the most sensible approach?

We should anticipate needing further releases fairly soon, of at least mod-circulation (likely a minor and a major) for the service points related changes, and of mod-inventory-storage (minor) for the second phase of additional holdings properties (Niels Erik Nielsen correct me if I am wrong).

Comment by Jakub Skoczen [ 07/Nov/18 ]

Marc Johnson let's hold off on making releases for now. The ui- modules that you are referring to: are those snapshots (tip of master)? If so, are we saying that there is an expectation that for non-release (snapshot) versions of ui- modules all backend modules (with corresponding releases) need to be released?

Comment by Niels Erik Nielsen [ 07/Nov/18 ]

Marc Johnson that's correct; we merged but did not yet release first phase (minor) of holdings properties and there is an upcoming second phase (also minor) and a third phase (major) for holdings properties.

Comment by Marc Johnson [ 07/Nov/18 ]

Jakub Skoczen Ok, based upon that, and John Malconian comment yesterday, I shall not work on releasing any of these modules until further notice.

Whether the UI modules had already been, or were intended to also be released, for this initial build, was a question I was trying to figure out when to ask. I would like to gain a better understanding of what is intended to go in the environment and the process for updating it.

However, I deferred asking about that, as I wanted to be clear as to what the immediate requirements were for me, and didn't want to distract from that (or give the impression I was avoiding them).

Comment by Jakub Skoczen [ 08/Nov/18 ]

John Malconian Anton Emelianov Guys, my guess would be that the 'next-release' should include ONLY released modules, bottom to top, both UI and backend. Is this a valid assumption?

Comment by John Malconian [ 08/Nov/18 ]

Jakub Skoczen yes. absolutely.

Comment by Jakub Skoczen [ 14/Nov/18 ]

John Malconian Cool, so I think we are on the same page. If so, are you saying that some of the released UI modules are missing backend dependencies? If so which UI modules and versions are those? It would seem to be that it is a problem with the release process that would allow releasing modules with unreleased dependencies.

Comment by Marc Johnson [ 14/Nov/18 ]

Jakub Skoczen Am I understanding you correctly, that we need to check that an interface dependency is fulfilled by at least one formally released module version (excluding snapshots) during a dependent module release, and fail / deny the release if that isn't satisfied?

Comment by Jakub Skoczen [ 14/Nov/18 ]

Adam Dickmeiss is there a way to extend this message:

jenkins@8e6da5a15783:~/platform-core$ curl -X POST -d @stripes-install.json -H 'Content-Type: application/json' "http://next-release-core.aws.indexdata.com:9130/_/proxy/tenants/test1/install?simulate=true&preRelease=false"
Incompatible version for module mod-inventory-10.0.0 interface item-storage. Need 6.0. Have 5.3

so that we see what module needs the interface in question?

Comment by Jakub Skoczen [ 14/Nov/18 ]

Marc Johnson John Malconian Anton Emelianov we have discussed that Marc Johnson will investigate what is the cause for the above failure but will not attempt to perform any "recovery" releases right now, instead we will plan new releases for backend and front-end that will coincide with the Q4 release plan.

Comment by John Malconian [ 14/Nov/18 ]

jenkins@8e6da5a15783:~/platform-core$ curl -X POST -d @stripes-install.json -H 'Content-Type: application/json' "http://next-release-core.aws.indexdata.com:9130/_/proxy/tenants/test1/install?simulate=true&preRelease=false"
Incompatible version for module mod-inventory-10.0.0 interface item-storage. Need 6.0. Have 5.3

Just to elaborate on this particular error:

The following UI modules require item-storage 5.0 OR 6.0:

ui-checkin v1.3.0
ui-checkout v1.3.0
ui-inventory v1.4.0

mod-inventory-storage v13.0.1 provides item-storage 6.0
mod-inventory v10.0.0 also requires item-storage 6.0

So far so good. However, the last released version of mod-circulation v12.0.0 requires item-storage 5.3. In order to satisfy the mod-circulation requirement, an older version of mod-inventory-storage that provides item-storage 5.3 is enabled instead of v13.0.1. Since the UI modules require item-storage 5.0 or 6.0, the UI modules are happy, however, mod-inventory still requires 6.0.

Comment by John Malconian [ 14/Nov/18 ]

So I guess the next question is why didn't okapi attempt to downgrade mod-inventory to a version that requires item-storage 5. mod-inventory-9.5.0 requires item-storage 5.3. That's because there are other dependencies at play here. mod-inventory-9.5.0 provides inventory 6.4, however, ui-inventory needs inventory 7.0

Comment by Marc Johnson [ 15/Nov/18 ]

Thanks John Malconian for digging deeper into this.

UI Inventory requiring only inventory 7.0, which is provided only by mod-inventory 10.0.0 which requires only item-storage 6.0 effectively forces the resolution to item-storage 6.0 across the board.

Hmm, as far as I can tell, the latest tagged released version of mod-circulation 12.1.0 supports item-storage 5.3 or item-storage 6.0. This was done last week (https://jenkins-aws.indexdata.com/job/folio-org/job/mod-circulation/view/tags/job/v12.1.0/) and published to the registry (http://folio-registry.aws.indexdata.com/_/proxy/modules/mod-circulation-12.1.0).

I wonder what meant this wasn't picked up?

Maybe there is something else that is forcing resolution to item-storage 5.3 and so we have an unresolvable divergence. What I'm less sure about is why the conflict was discovered at mod-inventory.

Did you try this build yesterday?

Comment by John Malconian [ 15/Nov/18 ]

No, I haven't tried a build for a couple of weeks so it's probable the item-storage/mod-circulation issue has been resolved. I'll try another build today.

Comment by Marc Johnson [ 15/Nov/18 ]

John Malconian Thanks, I'll be curious to see if mod-circulation 12.1.0 is picked up and resolves this, or if there is something else driving this version conflict

Comment by John Malconian [ 19/Nov/18 ]

Next build error while attempting to build platform-core/next-release with releases only:

Incompatible version for module mod-users-bl-4.0.2 interface service-points. Need 2.1. Have 3.0

mod-inventory-storage 13.0.1 provides service-points 3.0 but the last release of mod-users-bl, v4.0.2 requires service-points 2.1. A new release of mod-users-bl compatible with service-points 3.0 is required.

Comment by John Malconian [ 25/Mar/19 ]

This issue has been essentially superceded/duplicated by FOLIO-1738 Closed and FOLIO-1739 Closed .

Generated at Thu Feb 08 23:14:22 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.