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

Gitea 'pages' #302

Closed
auuuuuzzzzzpallauzzzzz opened this issue Nov 29, 2016 · 32 comments
Closed

Gitea 'pages' #302

auuuuuzzzzzpallauzzzzz opened this issue Nov 29, 2016 · 32 comments
Labels
reviewed/wontfix The problem described in this issue/fixed in this pull request is not a problem we will fix type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@auuuuuzzzzzpallauzzzzz
Copy link

auuuuuzzzzzpallauzzzzz commented Nov 29, 2016

Let people have a repository to upload a static website, like github pages.


tldr: use software that integrate like:

@tboerger tboerger added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Nov 29, 2016
@tboerger tboerger added this to the 1.x.x milestone Nov 29, 2016
@tboerger
Copy link
Member

There have been already discussions about that in the past. This is a pretty huge feature and it requires additional domain/subdomain handling.

@auuuuuzzzzzpallauzzzzz
Copy link
Author

Why not instead just

  • let users have a repository called "project_name.pages.git"
  • let the website admin define a single suburl like "pages.hostname.com"
  • when Gitea detects the URL "pages.hostname.com/username/project" it automatically reads the HTML from "project_name.pages.git"

Maybe the URL is too long? Or are there security problems?

@tboerger
Copy link
Member

It must be a different domain because of security, otherwise somebody can inject malicious code that steals the session cookie.

@bkcsoft
Copy link
Member

bkcsoft commented Nov 29, 2016

this should be done with CI and a http-proxy (like nginx, træfik, etc)

@tboerger
Copy link
Member

Some static page feature should be nice, but first it requires a proper proposal so that somebody can estimate the requirements.

@bkcsoft
Copy link
Member

bkcsoft commented Dec 2, 2016

Even static page required the use of a different domain (because JS...). ALL other git services implement this by using a CI & http-proxy...

@tboerger
Copy link
Member

tboerger commented Dec 2, 2016

It must be a different domain because of security, otherwise somebody can inject malicious code that steals the session cookie.

But basic functionality to provide that can also be integrated into Gitea. Maybe at some point if we support plugins.

@bkcsoft
Copy link
Member

bkcsoft commented Dec 2, 2016

Well yes, we could build it... but unless we add multi-host we're screwed 😛

@tboerger
Copy link
Member

tboerger commented Dec 2, 2016

And to clarify all requirements and all the changes this needs i suggested a proposal ;)

@lunny
Copy link
Member

lunny commented Feb 23, 2017

In fact, we can start a new web service for the page on the same binary according to user's config.

@bkcsoft bkcsoft marked this as a duplicate of #2208 Jul 26, 2017
@bkcsoft bkcsoft mentioned this issue Jul 26, 2017
@ShalokShalom
Copy link

It's very easy to implement this with Caddy: https://caddyserver.com/docs/http.git

@techknowlogick techknowlogick added the reviewed/wontfix The problem described in this issue/fixed in this pull request is not a problem we will fix label Jan 23, 2019
@techknowlogick
Copy link
Member

Closing this as it can be better served by something such as Drone, Minio & Caddy together (or as @ShalokShalom mentioned, just caddy in itself).

@lafriks lafriks removed this from the 1.x.x milestone Jan 23, 2019
@ghost
Copy link

ghost commented Jan 29, 2019

A pages feature is the only reason I would use GitLab CE over Gitea.

@davidak
Copy link

davidak commented Jan 30, 2019

@archiebaer when you not want to setup your own server, have you considered hosting your static website at https://neocities.org/?

@pat-s
Copy link
Member

pat-s commented Feb 13, 2019

@ShalokShalom Is there any detailed guide on how to use caddy specifically with Gitea? Trying since hours to get this running :/

@ShalokShalom
Copy link

@pat-s Sorry for the delay. Did you get it running?

@pat-s
Copy link
Member

pat-s commented Feb 20, 2019

No, not yet. A guide would be highly appreciated.

@bricewge
Copy link

@pat-s Here is a working example where a hugo blog is build on the caddy server; note that you will need a caddy binary compiled with the git plugin.

@ShalokShalom
Copy link

Can we put this into the documentation?

@pat-s
Copy link
Member

pat-s commented Mar 1, 2019

Hm, I got my site working locally now. However, I cannot wrap my head around how I should serve/push it to the Gitea domain.

domain {
  root ./my-site
	git {
		repo        <git repo>
		path        .repo
		interval    3600
		then        R -q -e "bookdown::render_book('.', output_dir = '../')"
	}
}

I always get the following error:

acme: Obtaining bundled SAN certificate
2019/03/01 23:51:02 [INFO] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/K_LkKK7jteSA8vJzWcpIcP4HEzmrsK-aKLfEvUNENYg
2019/03/01 23:51:02 [INFO] acme: use tls-alpn-01 solver
2019/03/01 23:51:02 [INFO] acme: Trying to solve TLS-ALPN-01
2019/03/01 23:51:08 [geoinf.uni-jena.de] failed to obtain certificate: acme: Error -> One or more domains had a problem:

Also this video did not help.

How can I deploy the site to, let's say, <domain>/<repo>/<caddy> (https://123.org/repo/caddy)?

@bricewge
Copy link

bricewge commented Mar 2, 2019

@ShalokShalom You should write a PR to add it to the docs then.

@pat-s It doesn't look like a good idea to serve your website under the same domain as gitea #6163 (comment); Github and Gitlab are using subdomains to publish pages. Your error message is related to caddy automatic HTTPS but I don't think it's the right place to try to solve it, you can ask about it in the caddy's forum.

@ShalokShalom
Copy link

And post the solution here then, so others who find this post can relate. I can create an article for the docs then, have it not done by myself yet.

@hoijui
Copy link

hoijui commented May 1, 2019

Let's say I have everything setup: a caddy server with git support, ready to serve repos under a sub-domain.
How would I make it, so that if a gitea user creates a new repository, and uploads a g-pages branch, for example, it will be hosted on repo.user.sub-domain.domain? Or more specifically: how woudl I start a script that triggers the creation of a new sub-domain and directory on the cady server, clones the repo and sets up a hook so changes to the g-pages branch get published immediately?
So the question is mostly, about how to automate the process; how to trigger a web-repo-creating script from within gitea, when a new repo is created.

@hoijui
Copy link

hoijui commented May 1, 2019

btw, we plan to set this up while documenting it. if we manage to do so, the documentation wil be published (and lined to here)

@bricewge
Copy link

bricewge commented May 1, 2019

I don't think gitea can do that yet but it would be great to have this feature. A hacky workaround would be to use inotifywait or systemd's .path to monitor the creation of the directories $GITEA_WORK_DIR/repositories/*/g-pages.

@hoijui
Copy link

hoijui commented May 1, 2019

oh wow... thanks for the info.

so basically I would do this:

  • monitor $GITEA_WORK_DIR/repositories/*/* for the creation of new repos
  • for each new repo, install an update git hook (see end of page)
  • in this hook script, I would thenn call an other script, triggering the creation/update of a subdomain and web-server directory for this repo, if the g-pages branch is updated, if such repo does not yet exist

@hoijui
Copy link

hoijui commented May 1, 2019

links for documentation:

  • Caddy - static web server software (sources, APL 2.0)
  • Drone - CI/build-server/Continuous Delivery platform (sources, APL 2.0)
  • MinIO - object storage for AI (sources, APL 2.0) - Why would we want to use this/what for?

@ShalokShalom
Copy link

You could host it via IPFS: This means no Server are in place, all decentralised

@hoijui
Copy link

hoijui commented May 2, 2019

thats a good idea, but it woudl only cover a small part of it, namely content storage.
one would still need a build server, an IPFS gateway for ones content, sub-domain mapping to that content, and triggering of builds from gitea.

... or do we?
what if we setup a pre-push hook for all the devs, which would generate the static pages before pushing? is that feasible?
that woudl at least remove the requirement for a build-server.

@davidak
Copy link

davidak commented May 2, 2019

@hoijui everyone must have the build environment configured. Seems not very elegant, especially for website content editors.

IPFS would be a nice option, but i think it should not be default (yet).

@ShalokShalom
Copy link

@sblisesivdin
Copy link

Pages is a good idea, however it is just a "follow the leader" thing. Can wiki feature extended to make more elegant pages? Wiki is already implemented.

@go-gitea go-gitea locked and limited conversation to collaborators May 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
reviewed/wontfix The problem described in this issue/fixed in this pull request is not a problem we will fix type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests