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

Comments

@auuuuuzzzzzpallauzzzzz
Copy link

commented Nov 29, 2016

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


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@tboerger tboerger added this to the 1.x.x milestone Nov 29, 2016

@tboerger

This comment has been minimized.

Copy link
Member

commented Nov 29, 2016

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

@auuuuuzzzzzpallauzzzzz

This comment has been minimized.

Copy link
Author

commented Nov 29, 2016

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

This comment has been minimized.

Copy link
Member

commented Nov 29, 2016

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

@bkcsoft

This comment has been minimized.

Copy link
Member

commented Nov 29, 2016

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

@tboerger

This comment has been minimized.

Copy link
Member

commented Nov 29, 2016

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

@bkcsoft

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Dec 2, 2016

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

@tboerger

This comment has been minimized.

Copy link
Member

commented Dec 2, 2016

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

@lunny

This comment has been minimized.

Copy link
Member

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 referenced this issue Jul 26, 2017

Closed

Gitea Pages #2208

@ShalokShalom

This comment has been minimized.

Copy link

commented Jul 27, 2017

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

@techknowlogick

This comment has been minimized.

Copy link
Member

commented Jan 23, 2019

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

@archiebaer

This comment has been minimized.

Copy link

commented Jan 29, 2019

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

@davidak

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Feb 20, 2019

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

@pat-s

This comment has been minimized.

Copy link

commented Feb 20, 2019

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

@bricewge

This comment has been minimized.

Copy link

commented Feb 23, 2019

@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

This comment has been minimized.

Copy link

commented Mar 1, 2019

Can we put this into the documentation?

@pat-s

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Mar 7, 2019

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented May 1, 2019

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

@hoijui

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

@sblisesivdin

This comment has been minimized.

Copy link

commented May 4, 2019

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.
You can’t perform that action at this time.