Build docs for GitHub forks/branches (or pull requests)

[jodal]

Annotating commits on GitHub with the build status (see #238) would become a lot more useful if ReadTheDocs also built docs for forks and branches. Then pull requests would be able to say if changes to docs will build OK.

Another way to achieve this would be to build docs for any pull request to the main repo, ignoring forks and branches that never leads to pull requests.

[wraithan]

Adding support for forks is rather expensive and they'd have to have their post-receive hook setup and working as well. If I recall correctly forks do not inherit these.

Pull requests is more possible, but currently we don't have a way of dealing with any type of hook except for the post-receive. Also these forks/etc would be listed in the versions and such and I don't know if that is desirable (very easy to do malicious or at least troll-y things.)

[adamcik]

The way I imagined this would work when discussing this with @jodal was that there would simply be build for the sake of doing a lint / error check, as most likely there are few use cases for publishing random un-merged docs. While being notified that merging this pull request / branch / ... would break the docs / introduced an error up front would be awesome :-)

[wraithan]

I am conflicted on this. For linting purposes, it feels like something one should setup with their travis-ci stuff. But their environment is not the same as readthedocs so it wont give you a 100% accurate results.

For now I am -0 on building for purely linting/error checking purposes, would love to hear what you think @ericholscher

[wraithan]

Closing this, I've discussed it a few times and it is outside of the scope of Read the Docs.