More structured deployment process

[jupyterhub]

More structured deployment process

[yuvipanda]

@minrk cool! IMO not merging a PR when one doesn't have time to deploy right now is a good thing, rather than bad thing. Merging and not deploying sortof blocks other people from merging and deploying, since they now become responsible for your PR too.

[yuvipanda]

A lot has happened since this issue was filed, and I think we're in a good place now.

[yuvipanda]

/cc @willingc @betatim @choldgraf @minrk @Carreau @mariusvniekerk

[minrk]

👍 to this, and a first prototype is in progress on binderhub: jupyterhub/binderhub#222

The only possible downside I can see is an incentive to avoid merging a PR when one doesn't have the time to deal with the deploy (i.e. if I can't deploy right now, I also can't merge upstream PRs). I'm not sure that will be an issue, and it certainly doesn't mean we shouldn't give it a try.

[minrk]

Makes sense!

[willingc]

I think it's a reasonable workflow to approve the code after review. If there's not time / support at the moment to merge, there's no harm done by a second review by someone else who can then merge. We're pretty fluid in terms of merging in a timely manner.

[choldgraf]

I'm +100 on this idea, the "expect a failure on first deploy" is getting really annoying :-)

[betatim]

I like the proposal.

One thing that I would love to see is that we could deploy to staging when we open the PR. The workflow of open PR -> instantly merge -> revert because failure ... not sure how we'd organise for that but yeah it would be nice and feel more in line with how the rest of GitHub works.

[choldgraf]

We are currently planning on short-term dealing with this by having planned deploys with team-members present. Here's another +100 on this issue in case somebody has the cycles to automate a binderhub/repo2docker bump!