Gitea: Gitea 'pages'

Created on 29 Nov 2016  路  32Comments  路  Source: go-gitea/gitea

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.

kinproposal reviewewontfix

Most helpful comment

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

All 32 comments

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

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?

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

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

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

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

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.

Well yes, we could _build_ it... but unless we add multi-host we're screwed 馃槢

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

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

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

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

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

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

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

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

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

@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.

Can we put this into the documentation?

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)?

@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 https://github.com/go-gitea/gitea/issues/6163#issuecomment-466601351; 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.

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.

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.

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)

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.

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

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?_

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

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.

@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).

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

internalfx picture internalfx  路  3Comments

thehowl picture thehowl  路  3Comments

kolargol picture kolargol  路  3Comments

jorise7 picture jorise7  路  3Comments

kifirkin picture kifirkin  路  3Comments