Introduction
gitea is a DevOps platform alternative to GitLab or github for instance. In contrast to GitLab however it is focused on a lightweight and straightforward hosting experience under the MIT license.
Info
In gitea git hooks are already modified by the gitea server. See git Hooks for more information on how to integrate custom hooks.
Deploy gitea-Service
This docker container can be used as a light weight git server.
To deploy a gitea service the following Docker Compose file can be used:
version: "3"
networks:
gitea:
external: false
services:
server:
image: gitea/gitea:1.20.2-rootless
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
networks:
- gitea
volumes:
- <path_to_gitea>/data:/data:rw
- <path_to_gitea>/config:/etc/gitea:rw
- <path_to_gitea>/git:/var/lib/gitea/git:rw
#- /etc/timezone:/etc/timezone:ro
#- /etc/localtime:/etc/localtime:ro
ports:
- "<webui_port>:3000"
- "<ssh_port>:22"
Serve via reverse proxy
The original gitea reference can be found here.
Nginx
To serve gitea via a Nginx reverse proxy the following entry in the http domain has to be added:
server {
listen 80;
server_name <your_url>;
location / {
client_max_body_size 512M;
proxy_pass <gitea_url_or_ip>;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
git Hooks
In gitea git hooks are already modified by the gitea server. Thus, custom hooks have to be integrated accordingly.
To edit git hooks automatically in the background and include for instance a post-receive
hook, add it to the folder /hooks/post-receive.d/
instead of just the base folder /hooks/
. It will be called by the original post-receive
hook in the hooks
folder created by gitea.
To set up hooks manually however, the webui can be used. Within the settings of the repositories the section Git Hooks is available. In this section pre-receive
, update
and post-receive
hooks can be edited.
gitea Actions
Source:
- https://docs.gitea.com/usage/actions/quickstart
- https://www.reddit.com/r/Gitea/comments/120jwba/how_do_i_make_gitea_actions_build_docker/
Gitea Actions tries to be as compatible to GitHub Actions as possible. The syntax and the concept is completely identical.
In contrast to Woodpecker Gitea Actions uses a base container in which all jobs have to run. Thus, a container has to be run inside this base container if a containerized application shall be tested / used. Furthermore artifacts are not natively available in subsequent jobs - they will have to be cached and retrieved again.
In Woodpecker for every job a specific container can be defined in which the artifacts from previous jobs will directly be available. Thus, it is very easy to set up containers for specific reoccuring tasks and just use them a the container for a specific job inside a pipeline.
Webhooks
The original gitea reference can be found here.
To use webhooks together with third party applications like Woodpecker the app.ini
file of gitea has to be adjusted. To do this it is a good idea to mount the /data
folder of the gitea Container to the host server. Then the app.ini
file can be adjusted and backups of its configuration can be created.
For webhooks it is important to set the environment variable ALLOWED_HOST_LIST
and populate it with the IP addresses of the host servers that will communicate with gitea via webhooks. Also don’t forget to restart gitea after this change.
Thus, the following information has to be added to app.ini
:
[webhook]
ALLOWED_HOST_LIST = <ip_of_host_server>
Container Registry
The original gitea reference can be found here.
If you have pipelines that need access to gitea repositories for pushing Container Registries and the connection to the gitea instance can not be TLS encrypted with a trusted certificate take a look at Pushing images to a registry.