Feedback wanted for Janitor - Discourse development in the cloud

published

#1

This post is going to be shared on Discourse Meta, when it’s ready


What the explative did I just watch?

That’s the Janitor, an on-demand developer environment service for OSS projects. It uses Docker to allow lots of dev envs to be cheaply colocated on powerful bare-metal servers and new environments to be launched very quickly. It’s mostly being developed by Mozilla employees because getting a Firefox developer box set up is hard and compiling it requires monstrous amounts of computer, but it also just added support for Discourse.

Why do I care?

With Janitor, developers can get started with a Discourse developer environment by logging into a website and clicking a button. They can also start as many of them as they want.

  • This should help new contributors, new plugin developers, and non-techie theme designers, because they can skip the UAC/admin prompts, BIOS settings (if you’re using vagrant), and command line. Using the Janitor literally just involves visiting a web page and clicking buttons within it; you cannot mess up your computer, so getting started with it is safe. And if you mess up a container, you can delete it and start again.

    This is especially important for designers, who should never be required to set up a local dev environment.

  • This can help testers, because you can spawn as many dev environments with slightly different configurations as you want.

  • This can provide a fallback, if you drop your dev laptop in the toilet and are still waiting for the new one to ship.

How does it work?

Supporting a project basically means writing a Dockerfile to initialize an image. In Discourse’s case, we install dependencies like Ruby and PostgreSQL, clone the repo, and run the database migrations. Since the initialized database and cloned GitHub repo are baked into the image, creating your own Discourse development container doesn’t even require GitHub to be up.

The base image used by all the Janitor project images (janx/ubuntu-dev) also contains stuff that runs in your container that Janitor needs to work right, particularly a copy of the Cloud9 SDK.

Also, you have root access to the container. So go nuts.

What’s the catch?

Janitor still alpha-quality software. Also, we’re not compiling Discourse’s JavaScript or CSS assets like a production Discourse instance would, so the initial site load is slow.

Janitor is not a free service for hosting production instances of Discourse; not only does its firewall/proxy set up make that very impractical, it’s also not allowed. Blatant abuse like attacking Twitter, mining Bitcoin, or trying to break out of a dev container and gain access to the host system is also not allowed.

Does Janitor use Discourse?

Yes.


Ssh access to Discourse Janitor
#2

Title suggestion: “Feedback wanted for Janitor - Discourse development in the cloud”

There’s currently no other viable cloud dev environment for Discourse afaik, so this alone is enough to sell it. We’re a techy community so too many adjectives or broad statements could hurt your pitch rather than elevate it :wink:

The “feedback wanted” gives us a call-to-action; hopefully some discussion will follow suit.

It would also be prudent to think of some popular use cases. A few off the top of my head:

  • Theme designers. Knowing how to set up a local dev environment should not be a requirement for designers, but it currently is.

  • For first-time contributors who want just need to dive into some code tweaking to get their feet wet.

  • It’s a good fallback for anyone going through our plugin/dev tutorials. Sometimes a dev can’t get past the set-up stage, and we lose a prospective contributor in the process.

  • For testers, wanting to install a plugin for testing


#3

I went ahead and changed the title. I also tweaked the “Why should I care?” section to elaborate a bit more to elaborate on use-cases. By the way, I wiki-ed the post, so you should be able to edit it yourself (don’t worry; I can always revert it).

Cool. I probably shouldn’t have tried to tweak the standard “The Fastest Development System in the World” tagline; that tagline makes more sense when performance is getting in the way of development, and performance is not a major blocker for Discourse contributors.

Yeah, I was intending it for the “Why should I care?” section to handle that, but it wasn’t descriptive enough. I went ahead and elaborated it.


#4

#5