support environments from arbitrary github project

[progrium]

Based on assumptions set up in https://github.com/progrium/envy/issues/15 we can create a special case for jumping into environments built based on projects/repos that exist on any Github repo. This is particularly interesting for:

• new contributors that want to jump into development
• existing contributions/maintainers that need to quickly try something or fix-merge a PR

It's not meant as an ideal way to try a project, since that would most likely be running the project's standard Dockerfile or Docker Hub image. Instead, this is about having the development environment already set up.

Domains

Github is a particular domain. Obviously we're pretty dependent on them as is, but it would be good to support non-Github repos. That said, let's focus on a good experience for Github that should be extendable in the future.

Access

Environment names that start with a known domain name are treated as externally imported. Example: github.com/shazow/go-sshkit. This will produce an environment named gh-shazow-go-sshkit. The gh is the name of the known domain.

SSH

$ ssh progrium+github.com/shazow/go-sshkit@envy.host

HTTP

https://envy.host/gh/shazow/go-sshkit

Notice the name of the known domain is used as the path prefix. Based on authentication, it will create the resolved environment name gh-shazow-go-sshkit for the user. This is used internally. The URL in the browser will not change.

[fgrehm]

The hack I put together earlier today is up at https://github.com/progrium/envy/compare/master...fgrehm:devstep-hacks.

I noticed you've added the 0.2.0 milestone tag to this but I can remove the Devstep part of that branch and submit a PR in case you think it is worth to bring it in at this moment.

[progrium]

Nice PoC. Would like some other issues to shake out first.

[fgrehm]

I've cleaned up those hacks on my Envy monkey patch fork and one thing that I ended up doing was cloning the repo under ENV_ROOT/code so that it persists across multiple sessions.

@progrium In order to increase the chances of eventually promoting that into a PR, is this something you think we should do here? I don't want to go off on a tangent and end up relying on some behavior that will not be present on Envy's core :grin:

[progrium]

What were you doing before if not cloning the repo somewhere persistent?

I just might redo a lot of the Bash so let's just sync on functionality and behavior.

[fgrehm]

Hum... can't remember now, but giving it a second thought I might have messed up on the base image itself because I mounted it on a folder different from where I ADDed my code / set my WORKDIR somehow, sorry for the noise... I'm wondering if we can / should be smart about WORKDIRs and mount the code into the appropriate place inside the base image :thought_balloon:

Anyways, I just wanted to make sure I'm on the right track by making that persistent, I've accidentaly Ctrl+W on a vim session on the browser so many times now (and as a consequence closed the tab) that I just need to make sure I can't risk losing my changes by not making it persistent :sweat_smile:

[progrium]

Home and root directories are persistent. So it's a good idea to keep things there. /env will soon be /root/env. Work directories though I wanted to treat differently, but this feature definitely brings up work directories.

[jgallen23]

I've been putting my code in /root/code so it persists across all environments, but it probably doesn't make sense to put it there for project specific envs. Maybe /code is persisted for just that specific environment?

Whats the reason to move /env to /root/env? Isn't everything in /root shared across all envs?

[progrium]

https://github.com/progrium/envy/issues/3

/code isn't great because there are plenty of repos that might not be code. Maybe /work. So maybe make an issue discussing a /work directory and the behaviors around it.

[jgallen23]

I added a shared /work directory and submitted a pull request #39. We can discuss further there.