DEV Community: Diogo

Self-hosted Gitea CI

Diogo — Mon, 05 Jan 2026 19:01:48 +0000

The goal of this guide is to turn your Gitea from a simple code repository into a full automation pipeline. We’ll use Gitea Actions, which is compatible with GitHub Actions syntax, making the process straightforward if you already know GitHub CI/CD.

1. The Concept: Gitea Actions and Runners

Unlike GitHub, where the machines that execute workflows (Runners) are provided by Microsoft, in a self-hosted environment you must run your own Runner.

Since your Gitea is already running in Docker, the most natural approach is to create a sibling container that acts as the Runner.

2. Enabling Actions in Gitea

First, you need to explicitly enable Actions in Gitea.

Edit the Gitea configuration file (usually located at gitea/conf/app.ini).

Add or update the following section:

ini
[actions]
ENABLED = true

Restart the Gitea container to apply the changes.

3. Creating the Gitea Runner (The Worker)

Now you need a service that continuously listens to Gitea and waits for jobs.
We’ll use the official act_runner.

Create a docker-compose.yml file for the runner (it can be in the same compose file as Gitea or a separate one):

services:
  runner:
    image: gitea/act_runner:latest
    container_name: gitea-runner
    environment:
      - CONFIG_FILE=/config.yaml
      - GITEA_INSTANCE_URL=http://192.168.x.x:3000
      - GITEA_RUNNER_REGISTRATION_TOKEN=<TOKEN_HERE>
      - GITEA_RUNNER_NAME=thinkpad-runner
    volumes:
      - ./data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    restart: always

Getting the Runner Registration Token

Go to Site Administration → Actions → Runners → Create new Runner.
Copy the generated token and paste it into the GITEA_RUNNER_REGISTRATION_TOKEN field.

4. The Workflow: From Push to Deployment

Inside your repository (for example, a Next.js or Python project), create a workflow that defines what happens when code is pushed.

Create the following file:

.gitea/workflows/deploy.yaml

Below is a simple end-to-end example.

Scenario:
You push new code to main, a Docker image is built, pushed to a registry, and the production container is updated automatically.

name: Deploy to Production
run-name: ${{ gitea.actor }} is deploying 🚀

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Login to Docker Hub (optional)
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: your-user/your-app:latest

      - name: Update production container
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.HOST_IP }}
          username: ${{ secrets.HOST_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            docker pull your-user/your-app:latest
            docker stop my-app-prod || true
            docker rm my-app-prod || true
            docker run -d \
              --name my-app-prod \
              -p 8080:80 \
              your-user/your-app:latest

Why a Separate production Branch Is Usually a Bad Idea

You might consider creating a production branch and having Gitea automatically merge main into it.
In practice, this often introduces unnecessary complexity.

Modern CI/CD follows Trunk-Based Development principles:

main is the single source of truth
Code merged into main must always be production-ready
CI/CD builds and deploys directly from main

This eliminates manual merges, reduces errors, and keeps the pipeline simple.

Optional: Mirroring the Repository to GitHub

Even when using Gitea as your primary Git platform, mirroring your repository to GitHub can be a strategic advantage rather than a contradiction.

Why Mirror to GitHub?

Visibility & Portfolio

GitHub is still the most widely used platform by recruiters and open-source communities. Mirroring ensures your work is publicly visible without changing your main workflow.

Backup & Redundancy

Your self-hosted Gitea remains the source of truth, while GitHub acts as a read-only backup.

Ecosystem Compatibility

Some tools, integrations, and third-party services still only support GitHub natively.

Zero Workflow Impact

You continue pushing to Gitea, while GitHub stays automatically in sync.

How Gitea Repository Mirroring Works

Gitea supports one-way and two-way mirroring.

For most setups, one-way push mirroring is the safest option:

Gitea → GitHub
Main branch remains authoritative
No accidental changes coming back from GitHub

Setting Up Push Mirroring (Gitea → GitHub)

Create an empty repository on GitHub
In Gitea, open your repository settings
Navigate to Settings → Repository → Mirroring
Add a new push mirror
Use the GitHub repository URL (SSH is recommended)
Add your GitHub SSH key or token (example: git@github.com:your-name/your-repo.git)
Enable Push Mirror
Save the configuration

From this point on, every push to Gitea is automatically mirrored to GitHub.

Recommended Best Practices

Disable GitHub Actions on the mirrored repository Gitea remains responsible for CI/CD.
Protect the GitHub repository Treat it as read-only to avoid divergence.
Mirror only main (optional) Keeps the public repo clean and focused. Mental Model
Gitea = Source of Truth
GitHub = Public Mirror / Backup
CI/CD = Gitea Actions

This setup gives you full ownership and control, while still benefiting from GitHub’s network effects.

Summary: Key Benefits
Automation

No more SSH access and manual git pull on the server.

Observability

Each build and deployment is logged and visible directly in the Gitea UI.

Safety

If the build fails (syntax errors, failing tests, broken TypeScript or Python code), the deployment is automatically blocked, keeping production stable.

How a Binary Search Tree Works

Diogo — Sun, 07 Sep 2025 14:03:20 +0000

A Binary Search Tree (BST) is a special type of binary tree that organizes data in a way that makes searching, inserting, and deleting efficient. It is widely used in computer science because it combines the structure of a binary tree with the efficiency of a sorted dataset.

Structure of a BST

A binary search tree is made up of nodes, where each node has:

A key (or value)
A reference to a left child
A reference to a right child

The key property of a BST is:

Left Subtree Rule: All values in the left subtree of a node are smaller than the node’s value.
Right Subtree Rule: All values in the right subtree of a node are greater than the node’s value.

This ordering ensures that the tree remains sorted.

Searching in a BST

The search process follows the BST property:

Start at the root node.

Compare the target value with the current node:

If the target is equal to the node’s value → Found.
If the target is smaller → Move to the left child.
If the target is greater → Move to the right child.

Repeat until the value is found or the search reaches a null reference (meaning the value does not exist in the tree).

This process has an average time complexity of O(log n), assuming the tree is balanced.

Insertion in a BST

To insert a new value:

Start at the root and compare the new value with the current node.

If the new value is smaller, go to the left child; if greater, go to the right child.

Repeat until you find an empty spot (null), then insert the new node there.

By maintaining the BST property, the tree remains sorted after insertion.
Deletion in a BST

Deleting a node is slightly more complex and has three cases:

Leaf Node (no children): Simply remove the node.
One Child: Remove the node and connect its child directly to its parent.
Two Children: Find the node’s inorder successor (the smallest value in its right subtree), replace the node’s value with it, and then delete the successor.

Conclusion

A Binary Search Tree is a powerful data structure that enables efficient searching and organization of data. Its simplicity makes it fundamental in computer science, while its limitations highlight the need for more advanced balanced tree structures in real-world applications.

Using GORM as an ORM in Go: A Quick Overview

Diogo — Sun, 03 Aug 2025 11:00:00 +0000

GORM is one of the most popular Object Relational Mappers for Go. It provides a clean, expressive API for interacting with databases, abstracting away much of the boilerplate SQL code while still allowing fine-tuned control when needed.

Getting Started

To start using GORM, first install the library:

go get -u gorm.io/gorm
go get -u gorm.io/driver/sqlite # or another driver like mysql/postgres

Then, set up a simple connection:

import (
    "gorm.io/gorm"
    "gorm.io/driver/sqlite"
)

db, err := gorm.Open(sqlite.Open("test.db"), &gorm.Config{})
if err != nil {
    panic("failed to connect database")
}

Defining Models

You define your data structures as Go structs. GORM uses reflection to map these to database tables:

type User struct {
    gorm.Model
    Name  string
    Email string
}

Basic Operations

Create:

db.Create(&User{Name: "Alice", Email: "alice@example.com"})

Read:

var user User
db.First(&user, 1) // find user with ID 1
db.Where("name = ?", "Alice").First(&user)

Update:

db.Model(&user).Update("Email", "new@example.com")

Delete:

db.Delete(&user)

Why Use GORM?

Productivity: Less boilerplate, cleaner code.
Portability: Works with multiple databases.
Flexibility: Lets you drop down to raw SQL when needed.

Downsides

Slightly larger binary size.
May not be the fastest for high-performance use cases — consider raw SQL or sqlx if needed.

Conclusion

GORM is a great tool for building Go applications that need reliable database interaction with minimal friction. It’s especially useful for rapid development, small to medium-sized apps, and teams looking for readability over raw performance.

[Boost]

Diogo — Sun, 27 Jul 2025 16:13:28 +0000

The difference between Kanban and Scrum from a developer's perspective

Parizad ・ Jul 26 '25

#scrum #development #developer #developers

Understanding Go Modules: A Brief Guide

Diogo — Sun, 27 Jul 2025 14:42:43 +0000

A Go module is a collection of Go packages stored in a directory with a go.mod file at its root. This file defines the module’s path and its dependencies. It allows developers to version, upgrade, and manage dependencies cleanly.

Key Files

go.mod: Contains the module name, Go version, and required dependencies with their versions.
go.sum: Maintains checksums to verify the integrity of modules used.

Basic Commands

go mod init : Initializes a new module.
go get @: Adds or updates a dependency.
go mod tidy: Cleans up unused dependencies and adds missing ones.
go build / go run / go test: Automatically resolves and uses modules.

Benefits

No need for GOPATH.
Clear version control and reproducibility.
Easier to work across multiple projects.

Example

go mod init github.com/username/myproject
go get github.com/gin-gonic/gin@v1.9.0

This will create a go.mod file and fetch the specified version of the Gin web framework.

Go Modules make dependency management in Go modern and efficient, especially important as projects grow in complexity.

Atomic Commits

Diogo — Mon, 21 Jul 2025 18:52:18 +0000

Why You Should Use Atomic Commits
If you've ever scrolled through a Git history and struggled to understand what changed and why, you're not alone. This is where atomic commits come in — a simple but powerful practice that can level up your workflow.

What Are Atomic Commits?
An atomic commit means that each commit is small, self-contained, and focused on a single purpose. It should answer:

“What is the smallest meaningful change I can make and commit right now?”

Instead of dumping multiple unrelated changes into one commit, you break them down into logical units — fixing a bug, adding a feature, or refactoring a method.

Why It Matters
Better Code Reviews: Smaller commits are easier to understand and review.

Easier Reverts: A single bad commit? No problem. You can safely roll it back without undoing unrelated changes.

Clearer History: Your Git log becomes readable and meaningful — like a story of your codebase.

Less Merge Hell: Smaller, isolated changes reduce merge conflicts.

Good vs Bad Examples
Bad Commit:

git commit -m "fix bugs and add new feature and update styles"

Atomic Commits:

git commit -m "fix: handle null values in user input"
git commit -m "feat: add password visibility toggle"
git commit -m "style: update button padding"

Tips for Writing Atomic Commits

Stage changes selectively (git add -p)
Use clear and consistent commit messages (e.g., conventional commits)
Commit often, but with intention — each commit should have a purpose

Atomic commits take a bit more discipline, but they pay off quickly — especially in team environments. Clean history, fewer bugs, and better collaboration. Worth it.