GPII-3228: Implement changes in the provisioning and npm scripts in order to produce automatic installers on CI #51
Conversation
Removed Installer.ps1 from Vagrantfile so the installer is not being created anymore at provision time. Now it is a npm script so it can be called from CI. Added several new npm scripts: * installer:build - build the installer * installer:setVersion - set the version in package.json * installer:rename - rename the resulting installer according to the version number generated by fluid-publish Also, added the following top level npm scripts: * buildDevInstaller: it calls installer:build * buildReleaseInstaller: it calls installer:setVersion, installer:build and installer:rename And included a new powershell script that performs the renaming of the installer.
| "buildDevInstaller": "npm run installer:build", | ||
| "buildReleaseInstaller": "npm run installer:setVersion && npm run installer:build && npm run installer:rename", | ||
| "installer:build": "powershell -NoProfile -ExecutionPolicy Unrestricted -Command ./provisioning/Installer.ps1 -provisioningDir './provisioning'", | ||
| "installer:setVersion": "git config core.fileMode false && powershell -NoProfile -ExecutionPolicy Unrestricted -Command fluid-publish --test cleanCmd='echo NOOP'", |
There was a problem hiding this comment.
This is a bit funky - didn't we decide to from now on only ever roll installers/builds from npm artefacts? In which case we should be able to just fish this value from our own package.json
There was a problem hiding this comment.
This is funky, yes. Let's say that this is a first spike on this, given that we would like to start creating installers automatically as commits get into master (or better said, in the "cloud-one" branch very soon), no matter whether they are ready to be shipped or not.
In an ideal release model, I would expect the "releaser" to publish the artifacts on npm, commit the bumped version of the module and create the installer locally.
In fact, I'm not sure we want to perform a real "release" after every commit/pr gets into master. Another approach would be to only create an installer every time we bump the version in the gpii-app's package.json, but still, automatic creation of installers as they land master is something that has been requested for some time.
Backing to your original question about rolling installers from npm artifacts, that would be the ideal thing to do, but would require some extra work in the provisioning scripts and on CI as well. I'm not sure whether you prefer to absolutely go for it now or just start doing "something" in line with what we would like to end up with and as a temporary way of providing installers in an automatic way.
Anyway, happy to know your thoughts on this, maybe it's worth having a call, at this moment, it's been just Alfredo and I who have tried to put all the pieces together and come up with this first step.
There was a problem hiding this comment.
Can CI just sneak the build number (ie, the "285" from the url in #51 (comment)) into a file?
There was a problem hiding this comment.
Can CI just sneak the build number (ie, the "285" from the url in #51 (comment)) into a file?
I guess that the output log is being stored in the CI but outside the windows VM, so I'm not sure this is a good approach, specially if we need to test this in a local dev environment.
|
CI job passed: https://ci.gpii.net/job/gpii-app-tests/285/ |
GPII-3446: Renderer coverage
Removed Installer.ps1 from Vagrantfile so the installer is not being
created anymore at provision time. Now it is a npm script so it can be called from CI.
Added several new npm scripts:
version number generated by fluid-publish
Also, added the following top level npm scripts:
and installer:rename
And included a new powershell script that performs the renaming of
the installer.