Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Review Apps #2464

Closed
ghost opened this issue Oct 19, 2016 · 5 comments
Closed

Support Review Apps #2464

ghost opened this issue Oct 19, 2016 · 5 comments
Labels
Improvement Minor improvement to code Status: blocked Issue is blocked on another issue

Comments

@ghost
Copy link

ghost commented Oct 19, 2016

Feature Request

Written from the perspective of a GitLab user

A user of a private instance of Read the Docs requested a nice-to-have feature: the ability to see the rendered form of a merge request that modifies a project's documentation.

It's a common practice for some project teams to involve non-developers in the documentation review process. The current best practice is to have contributors collaborate through the merge request process; a process that involves leaving comments on unrendered text (be that markdown or reStructuredText). Reviewing the rendered (and therefore structured) form of the content is just as crucial to ensuring high quality documentation as reviewing the text itself.

Therefore it would be beneficial if Read the Docs supported a Heroku-like feature called Review Apps in which the contents of a branch, submitted as a merge request, is built by Read the Docs, and posted to the merge request via the GitLab Commit Status API.

Read the Docs has support for GitLab webhooks tied to Push events, but that webhook support does not extend to merge request events.

The hook receiver could be extended to support the structure of a merge request event, but I believe the semantics of building documentation for a merge request will be different, as documentation generated from a merge request should be deleted upon the acceptance, or closing, of the merge request.

@agjohnson
Copy link
Contributor

So, a similar integration is already on our roadmap for GitHub, #1340 -- we can leave these issues separate for now.

I took a swing at this already, the API integration is not the problem. The issue is in handling building of arbitrary versions, how to host them, and how to handle cloning of contributor repositories. I'll open a separate ticket here and shape up a milestone for these features. I'd like to see the GitHub integration first, GitLab and Bitbucket should be easy to implement after.

@agjohnson agjohnson added the Status: blocked Issue is blocked on another issue label Oct 19, 2016
@agjohnson agjohnson added this to the PR Integration milestone Oct 19, 2016
@agjohnson
Copy link
Contributor

Blocked on #2465

@ghost
Copy link
Author

ghost commented Oct 19, 2016

Issue #1340 is exactly what I was looking for.

A note about fetching the contents of a merge request, GitLab exposes a ref for each merge request against a target repository.

Documentation here - https://gitlab.com/help/user/project/merge_requests.md#checkout-merge-requests-locally

It allows you to fetch the branch from the target repository, even if the source repository is private.

I believe GitHub has the same thing, though I've never tried either in practice.

@humitos humitos added the Improvement Minor improvement to code label Dec 28, 2017
@stsewd
Copy link
Member

stsewd commented Aug 19, 2019

Isn't this the same as #1340 and #2465?

We have the feature in beta https://blog.readthedocs.com/building-docs-for-pull-requests/

@humitos
Copy link
Member

humitos commented Aug 20, 2019

They are the same to me. I think we can close it.

@humitos humitos closed this as completed Aug 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Minor improvement to code Status: blocked Issue is blocked on another issue
Projects
None yet
Development

No branches or pull requests

3 participants