Integrations
Tasks into Gitea
Connect a project to a Gitea repository and the tasks you choose open as issues there, with title, status and notes following them.
Development shops run two conversations about the same work. The client talks about it in plain words, on the task. The developers talk about it in the repository, on the issue, with the branch and the pull request beside it. Nobody should have to type it twice, and no client should have to read a stack trace.
Connecting a project to a Gitea repository does the first half: a task becomes an issue, and what happens to the task follows it there. Nothing comes back from the repository into the project — what a developer writes on the issue stays with the developers.
Connecting
Open the project, press Settings, then Integrations. Only admins see this page. In the Gitea card:
- Gitea address — the server itself,
https://git.example.com, without a path. - Repository —
owner/name, the way it appears in the address bar. - Access token — made on Gitea under Settings → Applications, with the issue scope. We check it against the repository before saving, and we keep it encrypted. The field empties after you save; leave it empty later to keep the token you already gave.
- Which tasks cross — only tasks with a label (the usual choice;
devunless you name another), or every task in the project.
Press Connect. From then on, a task that qualifies — created with the label, or given it later — opens an issue in the repository.
What crosses, and how
| On the task | On the issue |
|---|---|
| The task is created, or gains the label | An issue opens: acme-142 · the title, the description, and a line saying who opened it in sjTasks with a link back |
| The title is edited | The issue is renamed |
| Marked done or canceled | The issue is closed, with a line on it saying which |
| Reopened | The issue is reopened |
| In progress or blocked | The issue carries a status/in-progress or status/blocked label; open carries neither |
| A note is written | The note appears on the issue, prefixed with who wrote it |
The task page shows the issue as a chip — Issue #57 in owner/name — that opens it. Only a label you set, and only a task in a connected project, ever crosses. Files on a task do not.
What does not cross
Nothing from Gitea reaches the project. Not what developers write on the issue, not commits, not who closed what. This is the first half of the integration on purpose: a client reads every note on a task, and a developer's "rebased onto main" is not for them. When the other direction lands, a developer will choose what the client sees, line by line.
When something goes wrong
A repository that stops answering is not something the person who moved a task should hear about. Changes are sent in the background and retried; the Integrations page shows the last error and, if the repository refuses ten changes in a row, the connection switches itself off and says so there. Fix the token or the repository name and save to reconnect.
Disconnect forgets the token. The issues already opened stay in the repository, and the chips on the tasks still open them.