Create continuous integration demo
Description
Environment
Potential Workaround
is blocked by
Checklist
hideTestRail: Results
Activity
John Malconian June 26, 2017 at 2:35 PM
I think this can be closed now that folio-testing and folio-stable have been implemented.
Jakub Skoczen May 23, 2017 at 1:46 PM
As discussed on the call: John&Wayne to work on a Gdoc about issues around the demo system which will be then discussed and specific issues will get created.
Niels Erik Nielsen April 29, 2017 at 7:09 AM
Awesome, John.
Oh, right, I see the challenge with hyper-frequent UI commits and the back-end build being so heavy now.
Finally, as annoying as it may seem, the breaking is still a side benefit IMO.
Thanks!
John Malconian April 28, 2017 at 8:47 PM
I've created a 'development demo' Jenkin's build that consists of a "known" FOLIO backend configuration with the front-end using the HEAD of master so the build is triggered every time there is a commit to master branch of any of the UI/Stripes modules. t's at https://folio-uidev.aws.indexdata.com - However, there are a couple of issues with it.
The job can run several times of day and building the backend portion takes way too long each time. Rather than building the backend each time, performance can be improved by building an EC2 AMI (image) of the backend and versioning these backend images similar to the blackbox images. Will open separate issue for this.
The job frequently fails because new commits are typically breaking something else. I suppose that's the nature of CI testing.
Cate Boerema April 25, 2017 at 10:10 AM
Thanks, guys. This issue is really high priority for me, as I want to be able to verify stories when they are completed.
We relatively recently moved to using regular module releases for the public demo.
That means, new developments are not shown until the modules are properly released.
There's an ongoing discussion as to how often or how organized releases should happen - like once per development cycle in a coordinated fashion, or, whenever developers find that they completed new functionality in a given module.
So, for now it would be nice to have a CI demo as well, where progress can be verified, regardless of what release habits different teams or developers may apply.
A CI demo might regularly run into compatibility problems - that's why we left that model, I guess - but that can also happen to the demo based on releases (as is the case at the time of writing).