Deploying from Travis

[Snugug]

I'm attempting to deploy a site to Flynn from Travis, and I'm running in to a couple of showstoppers.

1. When attempting to install the CLI, there's a permission denied trying to write to /user/local/bin
2. Having renamed the filename to .flynn, trying to cluser add my cluster I'm getting an unknown cluster error

I've tried looking around, and I can't seem to find anyone deploying to Flynn from Travis or a working example. Here's my travis stuff:

language: node_js
node_js:
  - 'v5'

#########################
## Deploy
#########################
before_deploy: 'L=.flynn && curl -sSL -A "`uname -sp`" https://dl.flynn.io/cli | zcat >$L && chmod +x $L'

deploy:
  skip_cleanup: true
  provider: script
  script: sh ./.deploy.sh
  on:
    branch: master

#!/bin/bash

#########################
## Adapted from https://gist.github.com/domenic/ec8b0fc8ab45f39403dd
#########################
set -e # exit with nonzero exit code if anything fails

# Initialize Flynn
./.flynn cluster add -p ${FLYNN_CLUSTER} default ${FLYNN_URL} ${FLYNN_TOKEN}
./.flynn create ${FLYNN_NAME}

# Configure Git
git config user.name "Travis CI"
git config user.email "deploybot@travis.ci"

# Commit all the things into the repo
git init
git add .
git commit -m ":shipit: Deploy to Flynn"

# Force push to gh-pages
git push flynn master

[Snugug]

In addition to that, if I get all the way down to just adding the remote and trying to push to Flynn, I can't because Travis fails at the cert validation that Flynn needs and self-generates

[IsNull]

I'd like to hook in on this one with a quite general question: If I use a CI server (be it Travis), which ultimately builds the artefacts, wouldn't it be the best way that the CI deploys the artefacts on Flynn? I.e. push the (fat) jar to Flynn and not Flynn building it again?

[titanous]

Are the Travis builds public? Can you link to an example failure?

[hadifarnoud]

it could be very useful if someone writes an article on using any CI tool (Travis or otherwise) with Flynn.

[IsNull]

@hadifarnoud Well the purpose of a CI is to have ongoing tests on new commits and pull-requests. This is not really affected how you deploy, however, since both CI and Build-Pack Style deployment require you to have a completely automated build, one leads to the other.

The build-pack (Flynn) needs to compile the source to generate a slug / container.
The CI needs to compile the source to execute the tests.

This basically means that the CI is invoking the same build and test tool in your repository as later the build-pack is. This works and we currently use it that way. Some CI status badges are in the repositories so we can easily track if the build is alright.
Since our build for the build pack also executes the tests (and aborts if the test fail) this is some double work going on at Flynn. On the other hand, since you can deploy any commit to Flynn, even those which did not yet pass the CI, this is not really bad behaviour.

Now, this is of course just the Unit-Testing and limited integration testing. Having automated Integration Tests spanning multiple services deployed on Flynn would be another story. For now, we just go for a separate staging Flynn cluster and do tests manually.

If you or someone else has more thoughts on this I would be really interested.

Edit:
The way to only build on a CI would be to have the CI create and upload a (Docker) container from the build, which then can be deployed to Flynn. This could be automated.

[philiplb]

I will write a small article tonight about how we handle CI/CD here with Jenkins and the CD towards Flynn.

[philiplb]

@Snugug Here we go: https://philiplb.de/flynn/2016/10/04/flynn-cd/

[titanous]

Thanks @philiplb!

https://twitter.com/FlynnScale/status/783428265977454592

[philiplb]

Ou, nice, thank you. :)