Gitea Status Checks with TeamCity

When I switched from using GitHub to a self-hosted instance of Gitea for my projects, I initially thought I would lose the ability to have TeamCity report the status back to my Git server. TeamCity has support out of the box for GitHub, GitLab, and others, but not Gitea. It turned out to be quite straightforward to manually set up the same functionality with status reports to Gitea from TeamCity.

The goal is to have TeamCity update the status check in Gitea on every new commit that gets pushed to the repository.

Other than being able to see in Gitea if the build failed or passed, the status check can also be used to enforce rules preventing merging of the pull request until the check is successful.

Once set up, we'll see the status in the checks section and next to each commit, hopefully as a green checkmark.

Prefer video? The recording below contains everything in this article and more - subscribe to my YouTube channel for more content like this.

Gitea Access Token

For TeamCity to authenticate with Gitea to publish status updates, we're going to need an access token. Access tokens are managed and generated in Gitea under Profile → User Settings → Applications.

Under the section Generate New Token we can create a token for TeamCity to use.

TeamCity Commit Status Publisher

TeamCity can publish status to many different destinations out of the box using the Commit status publisher Build Feature. It offers choices from GitHub to Azure DevOps and pretty much anything in between. However, there is no option for Gitea.

Fortunately, Gitea's API is compatible with GitHub's API in this regard, and thus we can use the GitHub integration for status checks in Gitea from TeamCity.

With an access token ready to go, let's add the feature in TeamCity. Go to the project in TeamCity and edit build configuration → Build Features for the configuration that will publish status checks.

On this page, we can Add build feature, and we will choose to add the feature Commit status publisher.

As we will rely on the fact that Gitea's API is compatible with GitHub in this case, we'll choose GitHub as the option for Publisher.

This will default to a GitHub URL to something like https://api.github.com. We need to change this to the URL of a Gitea instance. The Gitea API is found at the endpoint /api/v1.

The URL is constructed like https://gitea-server.com/api/v1. If the Gitea server is located at something like https://gitea.foo.bar, the URL to the API would be https://gitea.foo.bar/api/v1.

Let's replace the URL https://api.github.com with https://your-gitea-server.foo/api/v1.

And finally, add the Gitea Access token we generated above to the Access Token field. And that's it; we should now be able to press the Test connection button and get a Connection successful response if everything has been set up correctly.

With that, we can save the settings for the Commit status publisher. The next time we make a build in TeamCity, the status of the build should be reported back to Gitea.

We now have a working status check in Gitea being updated on each build triggered in TeamCity.

Branch Protection

With TeamCity reporting the build status to Gitea in place, we now have the option to use this for branch protection. Go to the repository settings in Gitea and then Branches → Add New Rule to set up protection rules for a branch.

Personally, I like to protect my main branch to disallow direct pushes to it, and also require that all checks must pass before a branch can be merged into it. This ensures, for instance, that my test suite must pass before a branch can be merged into main.

To configure that rule, simply add main to the Protected Branch Name Pattern and then check the Enable Status Check checkbox.

Conclusion

Despite the fact that Gitea is not available as an option in TeamCity's Commit status publisher, it really is just as simple to set up, as it is with GitHub, thanks to the API compatibility.

This gives us a working status check in Gitea being updated on each build triggered in TeamCity. With a few steps, we can now see directly in Gitea the status of all our tests - whether they passed or failed - and we can also use this for branch protection.

Before this setup with TeamCity and Gitea, I had been using different setups based on GitHub with Jenkins or GitHub Actions. With the change to using TeamCity and Gitea, I've come very close to my ideal setup for operating my code repositories and automatic builds.