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:

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.