839605 - Allow users to submit repositories to the Demo Studio / Dev Derby

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Demo Studio / Dev Derby, enhancement)

Description

[John Karahalis [:openjck]]

What problems would this solve?
===============================
Developers already use (or should be using) source control in their workflow. By allowing those developers to submit their repositories to the Demo Studio and Dev Derby, updating an entry would be completely painless, and perhaps even automatic.

This could also provide some benefits to the Dev Derby. At the moment, a Derby submission cannot be changed after the contest has ended. But some developers do want to update their entries after a Derby has ended -- not for prizes, but just to show off their latest-and-greatest work. By hosting repositories, we could decouple the Derby entry (which should never be updated) and the underlying project (which could be updated at any time).

Who would use this?
===================
Demo Studio and Dev Derby contributors. My idea is that we should cater to both those contributors who are already using source control and those who have never heard of it -- we could this feature to /encourage/ them to do so.

What would users see?
=====================
The demo submission form should allow users to submit a repository as an alternative to uploading a Zip file. The form should also allow the user to submit a repository at a specific branch or tag, if he chooses.

For the Dev Derby, maybe the interface could allow ask the user for a repository (or branch of a repository) and a tag. The repository will be cloned at that tag and hosted as an entry. The author could change the tag any time before the contest ends, but not after the contest ends, to submit a new "snapshot" of the repository to the Derby.

What would users do? What would happen as a result?
===================================================
If the user submits a repository (or specific branch of a repository) to the Demo Studio, the demo should be updated automatically over time based on changes to that branch.

In the case of the Dev Derby, the Derby would host the repository as it existed at the "tag" that was submitted. At the same time, the Demo Studio could host a version of the demo that is automatically updated with changes to the branch. This allow us to "lock down" the entry that is submitted to the Derby but would still allow the developer the chance to update the underlying project on the Demo Studio.

Is there anything else we should know?
======================================
We talked about GitHub, but I wonder if we should generalize this to Git repositories in general.

I also wonder if we should make this the required demo submission process (and get rid of Zip uploads), but I know others disagree with me.

Comment 1

[Les Orchard [:lorchard]]

(In reply to John Karahalis [:openjck] from comment #0)

> Is there anything else we should know?
> ======================================
> We talked about GitHub, but I wonder if we should generalize this to Git
> repositories in general.

Not entirely, no, because the integration we've been talking about relies on the GitHub API and web-hooks functionality to react to changes to the repo. Those are not general git features.

We could probably accept the URL to a plain old HTTP git repo and a commit ID, but there'd be no auto-updates and the process would be much more complex.

> I also wonder if we should make this the required demo submission process
> (and get rid of Zip uploads), but I know others disagree with me.

I'm one who disagrees. As a rule of thumb, let's not pin features on one single 3rd party vendor.

Comment 2

[Les Orchard [:lorchard]]

Also FWIW, this would require an offline queue system (similar to bug 632082) to perform the process of cloning a repo and subsequent updates triggered off by web hook activity. I don't think there's any getting around the need for a queue here.

Comment 3

[John Karahalis [:openjck]]

Agree with both of your points in comment 1. Did not realize it would be so hard to generalize this to support other Git repos, and making this the only mechanism for upload doesn't work without that.

Comment 4

[Les Orchard [:lorchard]]

Another way to do it would be to try to go the Heroku git push route, and allow demo authors to git push to an end point we support with post-receive hooks to do whatever processing we need.

But, I say that as if I know what that would entail within Mozilla infrastructure, and if it's feasible in any reasonable amount of dev time. And I don't know about either, but I expect that would be a scary-big challenge - both dev-wise and security-wise.

Comment 5

[Les Orchard [:lorchard]]

And by "Heroku git push" I mean "Heroku-style / Heroku-inspired git push", not literally using Heroku as a vendor.

Comment 6

[John Karahalis [:openjck]]

No problem. I thought supporting other repositories would be relatively trivial, but seeing as it's not GitHub only sounds fine.

Comment 7

[ali spivak]

Demo Studio is being removed from MDN and archived as of end January 2016