[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Summary Continuously integrate and test new releases of both front-end and server-side components into Description Implement automated build pipelines for stripes platforms (platform-core and platform-complete) The PR test process includes the following quality gates:
Tools/Platforms Each platform git repository will be integated with a Jenkins pipeline responsible for coordinating Additional Outputs
Prerequisites/Considerations
Definition of Done
|
| Comments |
| Comment by Jakub Skoczen [ 24/Oct/18 ] |
|
John Malconian any relation to what we are discussing as 1. on
|
| 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 ] |
Just to elaborate on this particular error: The following UI modules require item-storage 5.0 OR 6.0: ui-checkin v1.3.0 mod-inventory-storage v13.0.1 provides 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
|