WORK IN PROGRESS - DO NOT MERGE YET: Deploy to Bluemix

[bradley-holt]

This pull request:

• Adds a "Deploy to Bluemix" button to the README (link currently points to the deploy-to-bluemix branch, which needs to be changed before merging this pull request)
• Adds a default manifest.yml file which declares and binds the following services:
  • IBM Cloudant
  • Watson Speech to Text
  • Watson Natural Language Understanding

[gr2m]

@bradley-holt look at @mmcelaney’s pull request here were she added deploy to Bluemix to another Hoodie app: https://github.com/hoodiehq/hoodie-app-tracker/pull/124/files

She also added .cfignore and a Procfile.

Another thing that might be a problem is that we depend on the ffmpeg binary to be available, I don’t know how @markwatsonatx made that work for the current deployment, can you check in with him?

[bradley-holt]

@gr2m Both .cfignore and Procfile already exist. They may need some modifications.

[bradley-holt]

Currently blocked on the following…

When using the "Deploy to Bluemix" button the app is automatically configured to use IBM Bluemix DevOps Services. The "Build Stage" is not configured how we need it by default. The first issue is that the default Node.js version is 0.10.40. A user may notice instructions that allow them to use Node.js version 4.2.2 instead. Completely undocumented is the fact that the user can configure the build to use Node.js version 6.7.0. The second issue with IBM Bluemix DevOps Services is that one needs to manually add a npm run build step to the build. The biggest problem here is that both of these are manual steps.

For reference, here is the needed configuration for the build step:

#!/bin/bash
# The default Node.js version is 0.10.40
# To use Node.js 0.12.7, uncomment the following line:
#export PATH=/opt/IBM/node-v0.12/bin:$PATH
# To use Node.js 4.2.2, uncomment the following line:
#export PATH=/opt/IBM/node-v4.2/bin:$PATH
# To use Node.js 6.7.0, uncomment the following line:
export PATH=/opt/IBM/node-v6.7.0/bin:$PATH
npm install
npm run build

Also, it appears that npm install is happening twice. Once in IBM Bluemix DevOps Services, and again in Bluemix itself. Not ideal.

Once one has manually configured IBM Bluemix DevOps Services correctly, the next blocker is with configuring the app to use the Cloudant service instance automatically created for this app. This could done by modifying the Procfile as such:

web: npm start -- --address=0.0.0.0 --port=$PORT --dbUrl=`node -e 'process.stdout.write(JSON.parse(process.env.VCAP_SERVICES).cloudantNoSQLDB[0].credentials.url + "/")'`

The problem is that the above Procfile will break the production app, as the production app does not use a Cloudant instance provisioned from within Bluemix.

[gr2m]

What we could do to unblock this for now is to not merge it into master, but keep a branch around that the "deploy to bluemix" button is pointing to.

The procfile could include the build step

web: npm run build && npm start -- --address=0.0.0.0 --port=$PORT --dbUrl=`node -e 'process.stdout.write(JSON.parse(process.env.VCAP_SERVICES).cloudantNoSQLDB[0].credentials.url + "/")'`

I guess if we add the build step to the Procfile, we don’t need the configuration for the build step and hence we wouldn’t have npm install run twice?

I am not sure what to do about the node version though :/ It looks like we use this buildpack, which defines Node v4 as default version? https://github.com/markwatsonatx/nodejs-buildpack/blob/master/manifest.yml#L5

[markwatsonatx]

There shouldn't be an issue with the Node.js version as we specify the required version in package.json:

"engines": {
  "node": "6.9.x"
}

Changing the Procfile alone, however, will not work as by default Bluemix will not install devDependencies. Originally I moved all devDependencies required to build the app to dependencies before we were uploading dist from Travis. I also used the postinstall script instead of overriding the Procfile, like so:

"scripts": {
  ...
  "postinstall": "npm run build"
}

I found that instead of moving dependencies around there is an environment variable we can set. I have a working Deploy to Bluemix button in the branch deploy-to-bluemix2. I made the following changes to make it work:

1. Procfile updated to use dbUrl from vcap
2. Added more memory to manifest.yml (required to run webpack - was running out at 1 GB)
3. Added FFMPEG_PATH environment variable to manifest.yml
4. Added NPM_CONFIG_PRODUCTION environment variable to manifest.yml

The only issue I see of running this in prod is the Procfile vs hoodie_dbUrl environment variable. Also, the postinstall will still run every time - even if dist is uploaded from Travis, so deployment will take longer.

[bradley-holt]

@gr2m @markwatsonatx

What we could do to unblock this for now is to not merge it into master, but keep a branch around that the "deploy to bluemix" button is pointing to.

I think this is probably the best option for now.

I guess if we add the build step to the Procfile, we don’t need the configuration for the build step and hence we wouldn’t have npm install run twice?

Yes, this is true. However, the "Deploy to Bluemix" button automagically sets up IBM Bluemix DevOps Services and I believe it adds a build step whether we want it or not (I forget if this is true or not, I'll have to test this again).

I am not sure what to do about the node version though :/ It looks like we use this buildpack, which defines Node v4 as default version?

The problem with the outdated node version is in Bluemix DevOps Services, not in the Bluemix runtime. The runtime, which is defined by the buildpack, seems to be fine.

There shouldn't be an issue with the Node.js version as we specify the required version in package.json

The issue here is with the version of Node.js used by Bluemix DevOps Services for the "build" step (which we probably don't even want anyways), not the runtime in Bluemix.

I have a working Deploy to Bluemix button in the branch deploy-to-bluemix2.

OK, I will take a look at this. Thanks!

The only issue I see of running this in prod is the Procfile vs hoodie_dbUrl environment variable.

I'm wondering if we instead of setting --dbUrl in the Procfile we should do the following before Hoodie is invoked:

1. Check if the --dbUrl CLI argument has been passed. If so, we stop here and do nothing.
2. Check if the hoodie_dbUrl environment variable is already set. If it is, we stop here and do nothing.
3. Set the hoodie_dbUrl environment variable based on the appropriate value(s) from the VCAP_SERVICES environment variable.

This assumes that Cloud Foundry allows us to set environment variable values at runtime.

[bradley-holt]

We may actually be able to use IBM Bluemix DevOps Services to our advantage. Since the "Deploy to Bluemix" button insists on automagically setting up IBM Bluemix DevOps Services anyways, we might as well work with the grain here. It appears that we can add a pipeline.yml file to the repository to declare the build process for IBM Bluemix DevOps Services. I'm going to explore this option.

[bradley-holt]

Made more progress on this:

• Build stage is working 🎉
• Region is specified in the pipeline.yml file, need to look and see if I can use an environment variable for this
• It's still installing npm depedencies redundantly in Bluemix (even though I delete the .cfignore file as part of the build) ☹️
• Still need to make dbUrl work
• Still need to add more memory in manifest.yml
• Still need to add the FFMPEG_PATH environment variable to manifest.yml
• Still need to add the NPM_CONFIG_PRODUCTION environment variable to manifest.yml