[FOLIO-690] folio-testing.aws.indexdata.com does not use latest stripes-connect etc. Created: 22/Jun/17  Updated: 12/Nov/18  Resolved: 26/Jun/17

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

Type: Bug Priority: P3
Reporter: Mike Taylor Assignee: John Malconian
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 6 hours
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-696 Rethink NPM package versioning for ge... Closed
relates to UIIT-29 Newly created Item records should be ... Closed
Sprint:

 Description   

As shown in the About page http://folio-testing.aws.indexdata.com/about this site is using:

  • stripes-core 1.14.1-SNAPSHOT.610
  • stripes-loader
  • stripes-connect 2.2.1
  • stripes-components 0.15.0
  • stripes-logger 0.0.2

(Ignore stripes-loader for the moment: it's a special case.)

As you can see, while we have a snapshot representing the latest stripes-core, we are using the most recent released versions of stripes-connect, stripes-components and stripes-logger.

This prevents some new facilities from working: for example, Charlotte Whitt is unable to verify the fix for UIIT-29 Closed .



 Comments   
Comment by John Malconian [ 22/Jun/17 ]

I just noticed that as well. Very strange. It should be picking up the latest snapshot versions but it isn't. Will check into this.

Comment by John Malconian [ 22/Jun/17 ]

So the good news is that the stripes components running on folio-testing are now all from tip of master. The bad news is that you won't know that by looking at the versions. I've had to roll back some of the changes I made previously in STRIPES-420 Closed . In short, NPM and semver don't work as you'd expect with pre-release tags. Turns out that, for example, 0.16.1-SNAPSHOT.23 > 0.15.0 is NOT true. So when stripes-core looks for other stripes dependencies like stripes-components and stripes-logger it wasn't actually getting the latest snapshots of those packages. I've disabled the changes I made in STRIPES-420 Closed for stripes-loader, stripes-connect, stripes-components, and stripes-logger only since these packages are really the only ones called bu other modules and stripes-core.

We should revisit this and try to come up with a better solution. I thought it best, however, to just make it work for now so that other things don't break.

Comment by Mike Taylor [ 22/Jun/17 ]

Thanks, John. But – I may be being dumb here – I don't understand. How have you got this running from the tip of master but displaying the version-numbers of the last releases?

Comment by John Malconian [ 23/Jun/17 ]

Mike Taylor Every time there is a commit to master, a build is triggered in Jenkins which, for Stripes and UI modules, essentially does an 'npm install' and 'npm publish'. The 'publish' is performed to a CI NPM repository. The package versions that are published are the same versions specified in the package.json and the existing package in the CI NPM repository from the previous CI build is overwritten with the latest one. That is why the package version is the same as the 'released' version but the contents are HEAD of master.

This is less than ideal of course, because you'd like more accurate information about which version of an NPM package you are using which is the problem I attempted to solve in STRIPES-420 Closed , however, because of the lame way NPM handles "prerelease" dependency resolution, the solution implemented in STRIPES-420 Closed caused problems with some of the core stripes packages which is why I've had to reverse some of the changes I made to how those core stripes dependencies are packaged for snapshot testing.

Let me know if this still doesn't make sense. I'd like to solve this problem for all NPM snapshot packages but, at the same time, I don't want to break everything while trying to figure out a better solution.

Comment by Mike Taylor [ 23/Jun/17 ]

Thanks, John, got it. The key bit I was missing i that you are now overwriting your previous build/install of the package each time.

0.16.1-SNAPSHOT.23 > 0.15.0 is NOT true

That is so broken it hurts. Is it special to "SNAPSHOT"? Could we use some other term?

Or just use super-high patchlevels, like 0.16.10003

Comment by John Malconian [ 23/Jun/17 ]

Super-high patchlevels is an interesting idea. I like it. Let me chew on that.

Comment by Mike Taylor [ 26/Jun/17 ]

John, why don't you close this one – since the actual bug is fixed – and add a new one for the nicer generated-package version numbers?

Comment by John Malconian [ 26/Jun/17 ]

Closing issue. Opened related issue FOLIO-696 Closed to investigate other solutions for CI package versioning.

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