Gitea Actions Tutorial
You set up Gitea Actions by turning on the feature and linking a runner. This gitea actions tutorial walks through runner setup, job files, and secret rules. Most teams start by giving a shared runner broad cloud and database keys. That fast setup works at first, but broad roles create risk later. Every build job can then read or change live data with no extra check. Core steps in a gitea actions tutorial Gitea Actions runs jobs when someone pushes code or opens a pull request. First, an admi
GitHub Actions Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up Gitea Actions by turning on the feature and linking a runner. This gitea actions tutorial walks through runner setup, job files, and secret rules. Most teams start by giving a shared runner broad cloud and database keys. That fast setup works at first, but broad roles create risk later. Every build job can then read or change live data with no extra check.
Core steps in a gitea actions tutorial
Gitea Actions runs jobs when someone pushes code or opens a pull request. First, an admin turns on the actions feature in the server settings. Next, you install the runner tool on a separate host machine. You register that runner with your Gitea server using a secret registration token.
Once the runner links to the server, it waits for new work. You define work by adding a workflow file inside your code repo. This file lists the events that start a job and the steps to run. Each step runs inside a container on the runner host.
Teams also store secrets in the repo or group settings page. The server sends these secrets to the runner when a job starts. The runner puts those keys into the job container so scripts can log in.
How runner roles and stored secrets work
Gitea lets you register runners at the server, group, or repo level. A server runner can pick up jobs from any repo on the system. A repo runner only runs jobs for that single code project. Most small teams set up one shared runner for the whole server.
Secrets follow a similar pattern across the system. You can save cloud keys or database passwords at the group level. Every repo in that group can then read and use those saved keys. When a workflow runs, the job gets full use of the secret value.
This native model handles basic build and test tasks well. It keeps passwords out of your git history and automates software checks. Teams can build containers, run unit tests, and push code without manual steps.
GitHub Actions Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native workflow permissions leave open
Native runner settings only decide which job gets a secret key. Once a step has the database or server key, it has full trust. The native setup does not check what individual queries or commands do in flight.
A bad script or a typo in a build file can drop tables. If a pull request triggers a job, outside code might read live keys. Even honest mistakes during a database change can wipe out user records. Standard logs only show that the runner logged in and ran a script.
You cannot see every query or shell command tied to the person who pushed. Also, if a job queries test data, raw emails or card numbers may appear. Data masking rewrites matched fields in results, such as phone numbers or national IDs. Without statement checks and masking, shared runners hold too much unchecked power.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How do Gitea Actions runners talk to the main server?
The runner polls the Gitea server over standard web ports to check for jobs. You do not need to open incoming network ports on the runner host. The runner pulls the job steps and sends back log lines as they run.
Should we use shared runners or repo runners for deploy jobs?
Use separate runners for jobs that touch live servers or production data. A shared server runner lets any repo run code on that same machine. Keeping deploy runners separate stops test repos from reaching sensitive network zones.
How can we limit risk from secrets stored in Gitea?
Scope your secrets to single repos instead of sharing them across whole groups. Give each runner key the smallest role needed for its specific task. Avoid storing static root database passwords in workflow settings whenever you can.