preview / render static html pages pushed to repositories (or gl-pages equivalent to gh-pages)?
For our working group we have a git-first-steps repo which contains an html presentation with "first steps"... Not only for presentations, but also for js demos, etc. it would be cool if gitlab allowed to "host" this out of the box.
Security needs some thought in this case though... (think about pushing a specially crafted html and sending a link to an admin). Maybe have it on a subdomain like "preview."... ?
We’re building this for GitLab EE:
Glavin Wiechert commented
I developed GitLab Pages (https://github.com/Glavin001/GitLab-Pages) for this purpose. Hope it helps you as well!
Samuel Leslie commented
Definitely in favour of this feature. In our use case, some of our developers store HTML documentation within repositories. The ability to view this documentation from within GitLab would be very valuable.
This functionality can be obtained in a simple form by editing "app/controllers/projects/raw_controller.rb" as follows:
- 'text/plain; charset=utf-8'
- elsif @blob.name =~ /(?:msi|exe|rar|r0\d|7z|7zip|zip)$/
+ if @blob.name =~ /(?:msi|exe|rar|r0\d|7z|7zip|zip)$/
Note this definitely has potential security ramifications and so should *only* be implemented if you know what you're doing and are confident your GitLab installation won't be exposed to any malicious users with commit access to repositories.
AdminGitLab team (Admin, Gitlab) commented
This functionality would have to be part of GitLab CI coordinator.
The following node server may help: https://github.com/developmentseed/jekyll-hook . It simulates GitHub's jekyll compiler sever.
What would be really cool is to compile things on the CI, then upload generated artifacts http://feedback.gitlab.com/forums/176466-general/suggestions/4522830-allow-access-to-build-artifacts-of-gitlab-ci to a server of your choice (S3?).
This would allow to reproduce GitHub's Jekyll (except for minor integrations like https://github.com/blog/1833-github-pages-3), but would be even more powerful as you could use any static site generator you want.
Beni Cherniavsky-Paskin commented
Github ended up moving from subdomains to separate domains, both for gh pages
and raw views:
Would it be feasible for all commits to be browsable and not just the head? IIUC Github originally served text/html raw views for any commit, then started forcing text/plain due to abuse, then created Pages as a replacement — but at the price of separate branch and only serving head.
Which prompted unofficial http://rawgithub.com which is invaluable for developement on website repos, e.g. to demo a bug or a PR at a specific commit...
James B commented
BTW, this used to work in older GitLab versions because the "raw" view of HTML was served as HTML; for security it's now served as text/plain (and rightly so!).
I think the best implementation would be as a subdomain, as the OP suggests -- this way any XSS attacks, etc, would be limited by Same Origin policy. Basically, shamelessly steal the `gh-pages` feature from GitHub :D
James B commented
+1, I'm surprised it took this long. Related: http://feedback.gitlab.com/forums/176466-general/suggestions/3701801-documentation-manager-or-documentation-storage
+1 I would love this kind of functionality.
Personally, I think using a separate branches was a bad design choice by GitHub: it would have been better to use specially named separate *repositories* instead: a repository named name.gitlab.io generates the page, but one without does not.
This is better because:
- it allows you to see all branches at once more easily
- is less confusing for beginners to set up