WIP: Support themes from external directory

[esune]

This review consists of the changes that are necessary to pull a theme for ToB from a directory that is external to the project folder. The build-theme.js and watch-theme.js scripts were updated to allow flexing on a new environment variable TOB_THEME_PATH that, if present, defines which directory holds the theme folder. The docker configurations (manage script and docker-compose.yml) were updated to support this new behaviour. Hot-reloading is a bit iffy, as it seems to work if I create/delete a file in the themes folder, but not if I update the contents of one of the files: this may be a Windows issue, so I'd ask @cywolf if he can double check it on OsX. The volume mounts seem to be correct, so I am unsure about what's going on there...

Openshift configurations have been updated as well, however I am not 100% sure about how would a build pulling the theme from a separate repo work, that will require more thinking and updates.@WadeBarnes if you have ideas please let me know: they still need to be tested, and I am not convinced the default path I specified in the TOB_THEME_PATH environment variable is correct (to pull from the current theme folder in the repo), but I would like to have a first opinion in case something is terribly off.

Please also note that I remobed the TOB_THEME environment variable from OpenShift deploymentConfigs AND from the service definitions in docker-compose.yml as this is a variable that is only used at build time, and it is therefore not required at runtime.

[WadeBarnes]

@esune and I had a discussion regarding the source code assembly and build management from an OpenShift perspective; how to checkout and build code from 2 separate repositories.

The best solution, at the moment, seems to be to use a Jenkins pipeline build to manage the process.

The Jenkins pipeline would perform an checkout scm of the main tob-web repository and the external theme repository to the same location. The result would be a single working copy containing the source code needed to build the UI with the customized theme.

The next step in the Jenkins pipeline would be to inject the assembled source code into an binary source build step. This step would replace the existing git source based angular build which produces the artifacts that are later copied into the run-time image.

Resources:

• https://stackoverflow.com/questions/35513355/openshift-s2i-build-strategy-from-multiple-data-sources
  • https://docs.openshift.com/container-platform/3.10/dev_guide/builds/build_inputs.html#binary-source
• checkout example - https://github.com/bcgov/TheOrgBook/blob/master/SonarQube-Jenkinsfile

[esune]

@WadeBarnes I think the last commit addresses your comment. I don't particularly like the fact that a bunch of variable names now need to be shifted into the Jenkinsfile rather than being in the BuildConfig, but I don' think there is another way.

I will try and poke around in my local minishift, but we should sync up about how we're going to test it in the cluster.

Please note: I rebased onto the latest master branch, hence the non relevant commits. Not sure why they are showing up, as they don't bring in any changes: is it maybe because my rebase re-signed those commits as well?