The Wombelix Post - sourcehut

New release of sr.ht go lib and terraform provider to fix update repo bug

2025-07-28T00:00:00+02:00

Today I released new versions of terraform-provider-sourcehut (v0.2.1) and the related Go library sourcehut-go (v0.1.1). This is a bugfix release to address an issue when updating a repository description.

End of last year, I published the initial version of the provider and library and started using it for my OpenTofu based management of my git repositories. When I tried to update the description of an existing repository, the provider failed with a very generic error:

Multiple API errors occured

This wasn't very helpful, so I started to dig into the code to find the root cause.

The issue was in the sourcehut-go library itself. The error handling for multiple errors was just returning a static string instead of the actual error details from the API. I improved the error handling to be more specific:

--- a/errors.go
+++ b/errors.go
@@ -4,6 +4,8 @@

 package sourcehut

+import "strings"
+
 // Ensure that the build fails if Error and Errors don't implement error.
 var _, _ error = (*Error)(nil), (*Errors)(nil)

@@ -34,7 +36,18 @@ type Errors []Error

 // Error satisfies the error interface for Errors.
 func (err Errors) Error() string {
-       return "Multiple API errors occured"
+       if len(err) == 0 {
+               return "[WARN] Errors.Error() triggered with err length 0"
+       }
+       if len(err) == 1 {
+               return err[0].Error()
+       }
+
+       var details []string
+       for _, e := range err {
+               details = append(details, e.Reason)
+       }
+       return strings.Join(details, "; ")
 }

 // StatusCode returns the HTTP status code of the request that unmarshaled this

With this change in place, the error message became much more useful:

A repository with this name already exists.; validation failed

This new error pointed me in the right direction. I checked the git.sr.ht legacy API documentation and found the problem. The API endpoint for updating a repository treats the name field as optional. If you provide a name that is different from the current one, it triggers a rename and a redirect. If you provide the same name, it fails because a repository with that name already exists.

To fix this, I changed the UpdateRepo function to only include the name in the payload if it's actually different from the old name.

--- a/git/git.go
+++ b/git/git.go
@@ -8,6 +8,7 @@ package git
 import (
        "bytes"
        "encoding/json"
+       "fmt"
        "io"
        "net/http"
        "net/url"
@@ -152,15 +153,25 @@ func (c *Client) NewRepo(name, description string, visibility RepoVisibility) (*
 // If repo.Name differs from oldName, a redirect from the old name to the new
 // name.
 func (c *Client) UpdateRepo(oldName string, repo *Repo) error {
-       jsonRepo, err := json.Marshal(struct {
-               Name string `json:"name"`
-               Desc string `json:"description"`
-               Visi string `json:"visibility"`
-       }{
-               Name: repo.Name,
-               Desc: repo.Description,
-               Visi: string(repo.Visibility),
-       })
+       updateData := make(map[string]interface{})
+
+       // Only include name if it's different from oldName (for renaming)
+       if repo.Name != "" && repo.Name != oldName {
+               updateData["name"] = repo.Name
+       }
+
+       // Always include description, allows empty as well
+       updateData["description"] = repo.Description
+
+       if repo.Visibility != "" {
+               // Validate visibility value
+               if repo.Visibility != VisibilityPublic && repo.Visibility != VisibilityUnlisted && repo.Visibility != VisibilityPrivate {
+                       return fmt.Errorf("invalid visibility: %s (must be public, unlisted, or private)", repo.Visibility)
+               }
+               updateData["visibility"] = string(repo.Visibility)
+       }
+
+       jsonRepo, err := json.Marshal(updateData)
        if err != nil {

I used the opportunity to refactor the code a bit and to add a value validation for the repo visibility.

With these two fixes, updating a repository description with my sourcehut terraform provider now works as expected.

The new versions are available in the OpenTofu and Terraform registry.

The OpenTofu Registry WebUI is often behind the API, even if it doesn't show v0.2.1 yet, it is already available. You can verify it by running curl https://registry.opentofu.org/v1/providers/wombelix/sourcehut/versions.

OpenTofu based management of my git repositories

2025-01-13T00:00:00+01:00

Yesterday I've completed the migration to git-repo-mgmt. It's an OpenTofu based management of my git repositories at Sourcehut with mirrors at Codeberg, Gitlab and GitHub.

I was tired to manually create repos across four platforms. Now it takes me seconds and a couple lines of code to do it, for example:

# SPDX-FileCopyrightText: 2024 Dominik Wombacher <dominik@wombacher.cc>
#
# SPDX-License-Identifier: MIT

module "git-repo-mgmt" {
  source      = "./modules/repos"
  repo_name   = "git-repo-mgmt"
  description = "OpenTofu based management of my git repositories"
}

The heart of the solution is a self written OpenTofu / Terraform module that does all the heavy lifting. It uses the sourcehut OpenTofu / Terraform provider that I recently publish and leverages AWS KMS for OpenTofu State and Plan Encryption.

On every push, builds.sr.ht is triggered and runs the mirror, setup, init, plan and apply phases as defined in .build.yml

The overall workflow looks like this:

git push
         > git.sr.ht
                     > builds.sr.ht
                                    > tofu apply
                                                 > sr.ht
                                                 > codeberg.org
                                                 > github.com
                                                 > gitlab.com

I'm very satisfied with the result, this makes things so much easier.

Release: sourcehut (sr.ht) OpenTofu / Terraform provider and Go library

2024-12-28T00:00:00+01:00

Today I released terraform-provider-sourcehut and the related Go library sourcehut-go into the wild. The majority of code is licensed under BSD-2-Clause. The provider is available in the OpenTofu and Terraform registry. The online version of the Documentation can be found there as well.

sourcehut-go is a Go SDK for accessing the sourcehut legacy REST API with oauth personal access tokens created via meta.sr.ht/oauth.

Both projects are based on the work of Sam Whited who archived the former code base on August 22, 2022.

My motivation to improve and release it: I plan to move my git repository management to OpenTofu. Providers for my usual mirror targets GitHub, Gitlab and GitLab are available. But there was no functional and published provider for sourcehut (sr.ht). Which I use as my primary code hosting and build platform.

Now that the library and provider are in a working state, I can continue to work on the actual project :D

Git repos moved to Sourcehut, with mirrors on Codeberg, GitLab and GitHub

2023-10-14T00:00:00+02:00

When I moved from a VPS to classic webhosting I had to shutdown my self-hosted git repos as well. I had Sourcehut on my list for years and decided it's finally time to test it. If you are used to (bloated) platforms like GitHub or GitLab, then Sourcehut is kind of shocking, in a positive way. Pure HTML, no JavaScript, every feature (git repos, docs, build service, wiki ect.) is a widely independent micro-service with it's own subdomain.

I really liked it and decided to go with a paid account, right now sr.ht is in alpha state and payment is optional. But alone the very nice build system and a fast loading page without tracking is more than worth it!

From now on, ~git/ redirects to git.sr.ht/~wombelix/, for better visibility, I decided to also mirror to codeberg.org/wombelix, gitlab.com/wombelix and github.com/wombelix.

I don't want to force someone to follow a specific process or be limited to a single platform, if you like my projects and want to contribute, use whatever site and workflow you prefer to create an issue or pull/merge-request, or send me a good old Email :).

If I should create a list or tracker on sr.ht and have a preferred process one day, I will add it to the README and/or CONTRIBUTE file in my projects.