12 — Actions (CI) and releases

Use Actions to run tests, build packages or publish files automatically on every commit.

Your first workflow

Add a file named .gitea/workflows/test.yml to the repository:

name: test
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "repository checked out"
      - run: ./scripts/test.sh

It starts running in the Actions tab the moment you commit. The runner registered on this server answers to the labels ubuntu-latest, ubuntu-24.04 and ubuntu-22.04; runs-on must be one of them.

Reading the logs

Actions → run → job → step: each step's output expands on its own. The red step shows where it stopped; you can re-run the whole thing from the top right.

When it should run

on:
  push:
    branches: [main]        # only on pushes to main
  pull_request:              # on every pull request
  schedule:
    - cron: '0 3 * * *'      # every night at 03:00

Secrets

Never write passwords or tokens into a workflow file. Define them under Settings → Actions → Secrets and use them like this:

      - run: ./deploy.sh
        env:
          TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Secrets are masked in the logs.

Publishing a release

When a piece of work is finished, tag it and create a release:

Releases → New Release.
Tag — something like v1.0.0. It is created if it does not exist.
Title and notes — what changed; the commit list helps.
Attach installers, archives or documents (Attachments).
Save it as a draft, or press Publish Release.

Every published release automatically offers source archives (.zip, .tar.gz) and permanent download links.

Tag or release?

Tag — a marker pinned to a point in history; it lives in git.
Release — the human side of that tag: notes, attachments, download counter.

Packages

The Packages tab lists package registries attached to your repository (npm, container, generic and more). Once you publish a package it appears here, with installation instructions on its page.