Feature request: support for deploying directly from a git remote

[olalonde]

It would be nice if the controller supported deploying apps by specifying a git remote URL. e.g. deis pull https://github.com/deis/example-nodejs-express.git or deis deploy https://github.com/deis/example-nodejs-express.git. That would make it easier to eventually have a "Deploy to Deis" button like Heroku.

[bacongobbler]

Would this be better resolved with a third-party plugin for the client? pulling a git repo and building it sounds a lot like git push to me, which one could write a plugin around the client:

$ cat << EOF > ~/bin/deis-deploy
#!/bin/bash
APP_NAME=$1
REPO=$2
echo "cloning $REPO to ./$APP_NAME"
git clone $REPO $APP_NAME
cd $APP_NAME
deis git:remote
git push deis master
EOF
$ chmod 755 ~/bin/deis-deploy
$ deis deploy myapp https://github.com/deis/example-nodejs-express.git

[olalonde]

That's just really difficult to do in a browser environment. There's https://github.com/creationix/js-git but it apparently doesn't support GH due to GH's CORS policy. I could always do the git clone/git push server side in deis dash but I'd prefer keeping the code base completely client side because it makes a lot of things simpler.

[krancour]

A couple thoughts... I do think it's a somewhat useful idea, especially in the context of a GUI like the one @olalonde is working on. Having said that, a feature of this magnitude is better tackled in v2. Over in v2 land, my crystal ball isn't always right, but I think builder may eventually be separated from Workflow and form the backbone of its own complimentary product... and I think that is where a feature like this would most logically live. My vote would be deferring this until we can do it right (and in the right place).

[olalonde]

@krancour I'd love to see the builder extracted as a standalone container/product because it would make those use cases easier:

1. using it to build non 12-factor web apps that run directly on k8s for example. I did this previously for a bittorrent server that ran directly on my CoreOS cluster and using the deis builder involved resorting to all sorts of hacks.

2. making it easier to test builds locally on developer machines without having to install and run the whole deis platform

[krancour]

using it to build non 12-factor web apps

This would not actually be possible, because the Heroku buildpacks all build 12factor apps.

This is getting philosophical here and is probably merely tangential to the OP, but fwiw, I think pre-built Docker images (using CI pipeline of your choice) + helmc / new helm looks to be a better approach for managing more complex applications, i.e. those built from a micro-service architecture.

[olalonde]

<offtopic>

@krancour I previously used the deis builder for building a non 12-factor app because

1. writing a Dockerfile that did everything the Deis build did for me would have taken me hours

2. With a separate CI pipeline, I would have had to manage yet another piece of infrastructure (or pay for a commercial solution which would be painful given that our cluster is under utilised and we're on a tight budget)

3. it was convenient to maintain build config with deis config

It was a ad hoc solution (I had a fleet unit file that pulled the image directly from the deis registry once it was built and made sure the deis app itself was scaled down to 0) but it worked relatively well.

I understand that maintaining a standalone CI pipeline is not a top priority for Deis though. On a related note, is there any you can recommend (preferably one that works well with Heroku buildpacks and produces k8s/helm ready images)?

</offtopic>