[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: |
|
||||||||||||
| Sprint: | |||||||||||||
| Description |
|
As shown in the About page http://folio-testing.aws.indexdata.com/about this site is using:
(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
|
| 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
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
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.
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
|