Enable Continuous Delivery

[maoo]

Background

As applied for the Symphony Java Sample Bots project, I'd like to enable Continuous Delivery on this project, so that everytime that Travis CI runs a successful build, the built artifact (uberjar) is deployed against the ODP

To accomplish this, I have:

• Created a project on Openshift Online (Developer Preview of v3, aka next-gen)
• Created a script-based integration between Travis CI and Openshift
• Created an container creation strategy based on Java binary as deployment unit, called s2i-java-binary

bot-unfurl

To test the deployment on this project, I've forked and applied the relevant changes:

• the .travis.yml file prepares the content to deploy and invokes oc-deploy.sh on after_success
• config-openshift.edn defines the user credentials that are read by environment variables

Travis CI successfully starts the Openshift build, which creates the container and triggers a new deployment.

Outstanding issues

The container execution is failing with the exception mentioned below; I'm still uncertain if the System/getenv syntax used in config-openshift.edn is working as expected. For completion, below are mentioned the environment variables that are available within the container.

Environment vars

• RUN_COMMAND - java -cp /opt/openshift/etc:/opt/openshift/bot-unfurl-standalone.jar bot_unfurl.main
• SESSIONAUTH_URL - https://foundation-dev-api.symphony.com/sessionauth
• KEYAUTH_URL - https://foundation-dev-api.symphony.com/keyauth
• POD_URL - https://foundation-dev.symphony.com/pod
• AGENT_URL - https://foundation-dev-api.symphony.com/agent
• TRUSTSTORE_FILE - [secret]
• TRUSTSTORE_PASSWORD - [secret]
• BOT_USER_EMAIL - [secret]
• BOT_USER_CERT_FILE - [secret]
• BOT_USER_CERT_PASSWORD - [secret]

Runtime exception

2017-02-15 15:06:31 DEBUG main:0 - Starting unfurl-bot...
Exception in thread "main" java.lang.RuntimeException: could not start [#'bot-unfurl.core/session] due to
    at mount.core$up$fn__216.invoke(core.cljc:92)
    at mount.core$up.invokeStatic(core.cljc:92)
    at mount.core$up.invoke(core.cljc:90)
    at mount.core$bring.invokeStatic(core.cljc:210)
    at mount.core$bring.invoke(core.cljc:202)
    at mount.core$start.invokeStatic(core.cljc:252)
    at mount.core$start.doInvoke(core.cljc:244)
    at clojure.lang.RestFn.invoke(RestFn.java:397)
    at bot_unfurl.main$_main.invokeStatic(main.clj:67)
    at bot_unfurl.main$_main.doInvoke(main.clj:55)
    at clojure.lang.RestFn.invoke(RestFn.java:397)
    at clojure.lang.AFn.applyToHelper(AFn.java:152)
    at clojure.lang.RestFn.applyTo(RestFn.java:132)
    at bot_unfurl.main.main(Unknown Source)
Caused by: java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast to java.lang.String
    at clj_symphony.api$connect.invokeStatic(api.clj:56)
    at clj_symphony.api$connect.invoke(api.clj:32)
    at bot_unfurl.core$fn__2455.invokeStatic(core.clj:28)
    at bot_unfurl.core$fn__2455.invoke(core.clj:27)
    at mount.core$record_BANG_.invokeStatic(core.cljc:86)
    at mount.core$record_BANG_.invoke(core.cljc:85)
    at mount.core$up$fn__216.invoke(core.cljc:93)
    ... 13 more

[pmonks]

EDN is a data-only format, and therefore you can't embed processing instructions (such as System/getenv) in it - the EDN reader will reject such content (as is happening in the exception above).

Furthermore, bot-unfurl uses a library called cprop for handling configuration, and amongst other benefits it's more flexible than System/getenv. I'll look at a solution based on that. How these environment variables interact with the existing config file will need some thought.

Finally, why have you flagged the locations of the certificate and truststore files, and the email address of the bot user as "secret"?

[maoo]

Certificate location is considered a sensitive info as it may suggest how (and from where) they are downloaded.

Email address is considered a sensitive info simply to avoid spamming.

[pmonks]

Should should be fixed in 7496050, via the use of aero which supports environment variables within config.edn. @maoo if you have a chance to test this, I'd really appreciate it - not sure when I'll have time to properly test environment variables myself.

[maoo]

Works like a charm, see https://github.com/maoo/bot-unfurl/commit/f57d04f70c2397cf0ea7610daa4bf7288dc8f4ed

I'm now stuck on javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown, more details on https://gist.github.com/maoo/7421f248cfabb0a538c385e40182949d .

I've tested different cacerts:

• Symphony Agent API server.truststore (includes godaddy, plus symphony.com and *.symphony.com certs)
• Standard OpenJDK 1.8 cacerts file
• A merge of the two (using keytool -importkeystore to copy certs from one to another)

This issue is reproduced locally; I can send over my certs/keystore on Symphony chat, in order to reproduce the issue.

[pmonks]

That exception is clearly showing that the SSL handshake between the JVM bot-unfurl is running in and the Symphony pod is failing. I've only ever seen this happen when the pod's SSL certificate hasn't been added to the truststore used by the JVM.

[maoo]

Stupid me, I forgot to register the certificate on the pod keystore; adding the bot-unfurl root certificate on the pod "Manage Certificates" UI fixed the problem. Thanks for the hint!

Now I got another exception trying to run locally, strangely a ClassNotFoundException - https://gist.github.com/maoo/5743d80abf9cb3ebe79cde847ef2ee66

[maoo]

Nevermind, issue fixed by last commit. the bot-unfurl is now running locally. I'll close this issue as soon as I have it deployed on Openshift Online

[maoo]

Openshift Online is running bot-unfurl against the ODP, closing issue.

[maoo]

Reopening issue, as I realised that the PR must be still submitted and merged.

[maoo]

Added OC_TOKEN environment variable into Travis CI; deployment on Openshift from latest Travis build was successful, see https://travis-ci.org/symphonyoss/bot-unfurl

Closing issue.