Hosting on GitHub FAQ

What are the options for hosting on GitHub?

There are two options to host on GitHub software:

1. GitHub.com, with which most people are familiar.
2. GitHub Enterprise, essentially GitHub in a box, which is deployed internally within an organization.

Why not host Mozilla’s canonical repositories on GitHub?

Four issues with hosting Mozilla’s repositories on GitHub:

1. No pre-receive hooks hooks - GitHub only supports post-receive hooks, which increases the requirements on developers to configure their environment and reduces Mozilla’s control over what is committed to our repositories. (For more information see What is the issue with post-receive hooks?)
2. Stable URLs - Hosting with GitHub.com decreases control over our repository URLs. We want stable URLs for linking in Bugzilla, pushlog, and elsewhere. (For more information see Why aren't GitHub URLs stable?)
3. Network availability and latency - This has been a problem causing build failures over the last year. This problem can be mitigated with internal mirrors but this increases the complexity for the releng team and requires running a Mozilla instance of Git. (For more information see Can we pay GitHub for improved availability?)
4. Limited permission support - This impacts our ability to limit commit access to portions of the tree. (For more information see What are the limitations of GitHub's permission system?)

What is the issue with post-receive hooks? Can we achieve the same functionality as we have with Hg?

Git has the ability to add pre-commit, pre-receive and post-receive hooks.

Pre-commit 

Run a hook before committing to a local repository. Pre-commit hooks operate on development machines. As such, there is a reduction in the level of trust in these hooks (they must be configured by developers) and an increase in developer machine configuration requirements.

Pre-receive 

Run a hook server side before accepting a pull request. Pre-receive hooks run on the server before a patch is integrated into Mozilla’s trees. This is the style of hook that is used with Mozilla’s Mercurial repositories today.

Post-receive 

Run a hook server side after accepting a pull request. This style of hook provides the ability to flag changes and take action after a change has been integrated in the tree.

The GitHub workflow supports pre-commit and post-receive hooks (via GitHub webhooks) only. The issue with post-receive hooks is that this puts us in a reactive workflow. What this means is that we can only react to issues after the fact. There is limited ability to prevent issues from occurring via pre-receive checks.

Why aren’t GitHub URLs stable?

GitHub URLs may be stable for some time. The question is, for how long. If we had looked to host Mozilla’s repositories five years ago, we likely would have looked at an alternative such as SourceForge. While SourceForge still exists, we have not heard any developer requests to use this service. Changing hosting companies in this way requires changing our URLs as well.

Why not use GitHub Enterprise?

GitHub Enterprise is essentially GitHub.com in a box. Using this option, we would deploy GitHub Enterprise within Mozilla. The benefit of GitHub Enterprise is access to the GitHub feature set on our own network. (We could have stable URLs in this case.) However, we have no plans to move away from Bugzilla and will continue to want patch/changeset review to take place in Bugzilla due to limitations securing review comments on pull requests. In this scenario, GitHub Enterprise is a costly deployment of a Git server that comes with hook restrictions.

Can we pay GitHub for improved availability?

GitHub does not provide this option at this time.

What are the limitations of GitHub’s permission system?

GitHub has basic LDAP authentication support but does not have group or more granular permissions.

GitHub.com is great for engaging the community. How can we engage the community?

We can mirror Mozilla’s repositories to GitHub for easy disoverability and cloning. Patches will need to be applied on Mozilla’s hosted repository. Several people (doublec, ehsan, releng) are already trying similar attempts. Whatever our approach it must work reliably at scale and be officially supported by Mozilla.

Will Mozilla require all repositories currently hosted at GitHub.com to move to a Mozilla’s owned server?

This has not yet been discussed and no decision has been reached.