Gogs CI: How to Run Builds for Gogs Repositories (2026)

Gogs (current release 0.14.3) has no built-in CI and no runner program, so you cannot register a runner with it. You run CI for Gogs repositories by pointing a Gogs webhook at an external CI server: Drone still ships a Gogs provider, and Jenkins can take Gogs webhooks through a plugin or a generic trigger. Woodpecker dropped Gogs in 1.0. If you want GitHub-Actions-style workflows, migrate to Gitea or Forgejo.

Gogs and CI: what exists today

Approach	Status in 2026	Runner / agent model
Gogs built-in CI	Does not exist	None
Drone + Gogs provider	Documented; Drone recommends Gitea over Gogs	Drone runners (docker, exec, ...)
Jenkins + Gogs webhook plugin	Works; plugin last released years ago, open security advisories	Jenkins agents
Jenkins + Generic Webhook Trigger	Works with any JSON webhook	Jenkins agents
Woodpecker CI	Gogs support removed in Woodpecker 1.0.0	n/a
Migrate to Gitea / Forgejo	Built-in Actions with runners	gitea-runner / forgejo-runner

The common thread: Gogs only tells another system that something happened. That system clones the repository, runs the build on its own workers and, if supported, posts a status back.

How Gogs webhooks drive external CI

In a Gogs repository open Settings, Webhooks, Add Webhook and choose the Gogs type. Fill in:

Payload URL: the CI server's webhook endpoint.
Content type: application/json.
Secret: a random string. Gogs signs the payload with it so the CI server can reject forged requests.
Events: push for branch builds, plus pull request if your CI handles PRs.

Gogs records each delivery under the webhook, with request and response. Use the Test Delivery button before you wire up a real build. Drone creates the webhook for you when you activate a repository; Jenkins needs it added by hand.

Option 1: Drone with the Gogs provider

Drone's documentation still lists a Gogs provider. Gogs has no OAuth, so users log in to Drone with their Gogs username and password. Drone itself warns that Gitea has better compatibility and that some features may not work with Gogs. Run the server:

openssl rand -hex 16   # use the output as DRONE_RPC_SECRET

docker run \
  --volume=/var/lib/drone:/data \
  --env=DRONE_AGENTS_ENABLED=true \
  --env=DRONE_GOGS_SERVER=https://gogs.example.com \
  --env=DRONE_RPC_SECRET=<rpc_secret> \
  --env=DRONE_SERVER_HOST=drone.example.com \
  --env=DRONE_SERVER_PROTO=https \
  --publish=80:80 --publish=443:443 \
  --restart=always --detach=true --name=drone \
  drone/drone:2

Set DRONE_GIT_ALWAYS_AUTH=true if Drone should authenticate when cloning public repositories. Then start one or more Docker runners on separate VMs. The runner talks to the server over the RPC secret:

docker run --detach \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  --env=DRONE_RPC_PROTO=https \
  --env=DRONE_RPC_HOST=drone.example.com \
  --env=DRONE_RPC_SECRET=<rpc_secret> \
  --env=DRONE_RUNNER_CAPACITY=2 \
  --env=DRONE_RUNNER_NAME=runner-01 \
  --restart=always --name=drone-runner \
  drone/drone-runner-docker:1

Activate the repository in the Drone UI, which adds the Gogs webhook, and commit a .drone.yml:

kind: pipeline
type: docker
name: default

steps:
  - name: test
    image: golang:1.23
    commands:
      - go test ./...

Drone runners support labels and node routing, autoscaling via the separate Drone autoscaler, and an exec runner for non-container builds. The Drone runners guide covers those in detail. Harness owns Drone today; read the current license terms and release activity on the Drone site before you build on it.

Option 2: Jenkins with Gogs webhooks

Gogs plugin

The Gogs-Webhook plugin (latest release 1.0.15, about seven years old) adds an endpoint that triggers a job by name:

https://jenkins.example.com/gogs-webhook/?job=<jobname>

It supports Pipeline and Multibranch Pipeline jobs, folders, a per-job Gogs secret and skipping commits tagged [IGNORE]. The Jenkins plugin site lists two unresolved advisories: unsafe default behaviour with information disclosure in the webhook (2023-08-16) and non-constant-time token comparison (2023-10-25). Expose the endpoint only on a network you trust if you use it.

Generic Webhook Trigger

The Generic Webhook Trigger plugin accepts any JSON payload, extracts values with JSONPath and triggers jobs that carry a matching token. Point the Gogs webhook at https://jenkins.example.com/generic-webhook-trigger/invoke?token=<token> and map $.ref and $.after to variables for branch and commit.

Jenkins runs the actual builds on agents. Put them on separate VMs or containers rather than the controller; the Jenkins agents guide covers static, cloud and ephemeral agents.

Woodpecker CI and Gogs

Woodpecker removed Gogs support in version 1.0.0, together with Coding and Bitbucket Server. A GitHub issue asked the maintainers to reconsider; Woodpecker 3.x still supports only GitHub, Gitea, Forgejo, GitLab, Bitbucket Cloud and Bitbucket Datacenter in core. Woodpecker does support addon forges, but no official Gogs addon exists. If a guide tells you to set WOODPECKER_GOGS=true, it describes a pre-1.0 version. The Woodpecker agents guide shows the current setup for supported forges.

Option 3: migrate to Gitea or Forgejo

Gitea started as a Gogs fork and Forgejo as a Gitea fork. Both ship Actions with self-hosted runners, so after a move you register a runner and write workflows in the GitHub Actions syntax. Two migration paths:

Repository by repository. On the new instance choose New Migration and pick Gogs as the source. Gitea and Forgejo import the Git data and, with an access token, issues, labels and milestones. This works with current Gogs releases.
In-place database upgrade. Gitea's docs describe this for Gogs 0.9.146 and older (more work up to 0.11.x). It requires stepping through Gitea 1.0.x and every later major. Gogs 0.12 and newer diverged too far for this path; use per-repository migration.

After migration, set up a runner with the Gitea runner guide or the Forgejo runner guide.

Security hardening

Always set a webhook secret and verify it on the CI side.
Serve Gogs and the CI server over HTTPS. Drone sends Gogs passwords at login.
Use a dedicated Gogs service account with read access for CI clones instead of a personal account.
Run builds on agents or runners separate from the CI server, and mount the Docker socket only on machines dedicated to CI.
Treat pull requests from forks as untrusted: build them without secrets or not at all.

Troubleshooting

Webhook delivery shows a timeout or connection refused

Gogs must reach the CI server's URL. Check DNS, firewall and TLS from the Gogs host with curl.

Drone login fails

Drone sends the username and password to Gogs. Check DRONE_GOGS_SERVER, and test the same credentials against the Gogs web login. Accounts with two-factor authentication need extra checks, since Drone only sends a password.

Drone build stays pending

No runner has connected. Compare DRONE_RPC_SECRET and DRONE_RPC_HOST on server and runner.

Jenkins returns 403 on the webhook

Jenkins security blocks the anonymous call. Point Gogs at the plugin endpoint (/gogs-webhook/ or /generic-webhook-trigger/invoke) instead of the job's build URL, and confirm the job name or token in the query string.

Cost trade-offs

A webhook-driven setup means two extra systems to run: the CI server and its workers. For a small team, Drone plus one runner VM is cheap in hardware but adds a component whose Gogs support gets little attention. Migrating to Gitea or Forgejo costs a few hours per instance and removes the separate CI server, since Actions lives inside the forge.

FAQ

Does Gogs have GitHub Actions or runners?

No. Gogs has no CI feature. Gitea and Forgejo, both descended from Gogs, have Actions.

Does Woodpecker CI work with Gogs?

Not since Woodpecker 1.0.0. Use Drone, Jenkins, or migrate to a forge Woodpecker supports.

Can I use GitLab Runner with Gogs?

No. GitLab Runner only registers with a GitLab instance.

What is the easiest CI for a Gogs server?

Drone with the Gogs provider needs the fewest moving parts, but migrating to Gitea or Forgejo gives you integrated CI.

Managed runners with cirunner.dev

cirunner.dev provisions a fresh VM per job, registers it with your CI using a token you provide, scales with the queue and destroys the machine after the job. You choose CPU, RAM, x86_64 or arm64, region, base image and an optional GPU, and pay per compute minute.

The service is in early access with GitHub Actions and GitLab CI at launch. Gogs is on the roadmap; vote for it on the early-access form.

CI for Gogs: webhooks, Drone, Jenkins and the move to Gitea or Forgejo