Implement SourceHut forge backend #5834

ddevault · 2025-12-06T10:16:29Z

This is an initial proof-of-concept. Will add remarks inline to highlight discussion points.

ddevault · 2025-12-06T10:18:02Z

server/forge/sourcehut/helper.go

+		c.gitURL, from.Repository.Owner.CanonicalName, from.Repository.Name,
+		update.New.Id)
+
+	return &model.Pipeline{


I could add changed files here, but would need to parse the unified diff to do so. Would it be desirable to add a dependency for that?

How much would that change the binary size? If it's not much we can add it I think.

Not much, probably. I think this one would do the trick:

https://godocs.io/github.com/bluekeyes/go-gitdiff/gitdiff

ddevault · 2025-12-06T10:18:49Z

server/forge/sourcehut/sourcehut.go

+
+func (c *SourceHut) Repos(ctx context.Context, u *model.User, p *model.ListOptions) ([]*model.Repo, error) {
+	// TODO: Pagination on SourceHut does not work well with Woodpecker's
+	// higher-level internals (and doesn't work well at all, to be frank)


SourceHut's API pagination leaves something to be desired, but one quality that needs to be considered is that it uses opaque strings for cursors, rather than integer page numbers, which requires higher level refactoring in Woodpecker.

ddevault · 2025-12-06T10:19:23Z

server/forge/sourcehut/sourcehut.go

+		entries = append(entries, &forge_types.FileMeta{
+			Name: ent.Name,
+			Data: data,
+		})


This interface design requires fetching the full contents of every file in a directory, including ones that may or may not be applicable to the workflow. Would be nice to separate these steps in the interface.

ddevault · 2025-12-06T10:19:56Z

server/forge/sourcehut/sourcehut.go

+		return err
+	}
+
+	// XXX: Ideally we would store the webhook ID here


It would be nice if forge backends could store arbitrary metadata in the database for, for instance, the repo table. This would allow us to store the webhook ID and simplify the webhook deletion process later.

ddevault · 2025-12-06T10:21:59Z

server/forge/sourcehut/sourcehut.go

+}
+
+func (c *SourceHut) PullRequests(ctx context.Context, u *model.User, r *model.Repo, p *model.ListOptions) ([]*model.PullRequest, error) {
+	return nil, nil // TODO


SourceHut does not have "pull requests". Instead, we use patches sent to a mailing list. By associating patches with a git repository, we can use features like status indicators, but right now there is no means of getting this information into the forge backend because it would require a separate UI for configuring which mailing list applies to a git repository.

This leads into another question, which is that the woodpecker frontend makes a lot of assumptions that the forge will use GitHub-style workflows like pull requests. The list of applicable events, and terminology like "pull request", would ideally reflect the capabilities/design of the underlying forge.

While this is right, changing this would probably add much complexity to the codebase. Having separate event handling for every forge would no longer allow us to let the UI define these labels, icons, etc. Also quite relevant features like the pull request gating is getting harder. Sure, it's possible, but I'm not sure if it's the right way to go (but I also don't know how complex that would be exactly).

About your first paragraph, can you elaborate some more here? Cause I don't know if I get that correctly. I never used sourcehut. Would it be possible to use the patches just (or mostly) like pull requests? Yes, there probably wouldn't be events like "pr closed" or "pr metadata updated". So the question mainly is if sourcehut can send a webhook linked to a repo if a patch comes in and if this patch can be cloned directly. If yes, this should work I think, if not, that would be hard to implement at woodpeckers side. And what do you mean by "separate UI"? A separate UI in woodpecker?

We can send a webhook indeed when a patch comes in, but it's not necessarily linked to a repository. A single mailing list can have several associated repositories within it, or vice-versa. We would need a separate UI to associate a repository (the resource known to woodpecker) with a specific mailing list to process patches from, which would basically involve a UI very similar to the one for picking a repository from a list of repositories present on the forge, only you would be picking out a mailing list instead.

Applying the patch for testing is not as simple as cloning it directly and checking out a magic reference like GitHub does, though. You need a separate step which basically amounts to curl <patch url> | git am -3.

As for the UI being able to accommodate different events and such for different forges, I agree that it will add complexity, though in this case we could probably just treat "patch" as a synonym for "pull request". But I think that it's a bit shortsighted to avoid having forge-specific UI tweaks on the basis that it adds complexity to the codebase; on the other hand it adds constraints to how well woodpecker can fit into each of the forges it supports. Currently all of the forges supported are GitHub-like, but they do still have differences which would probably be accounted for in Woodpecker, and it's pretty limiting to suppose that Woodpecker will only be able to support GitHub-like forges.

ddevault · 2025-12-06T10:22:34Z

server/forge/sourcehut/sourcehut.go

+		IsUser:  true,
+		Private: false,
+	}, nil
+}


SourceHut does not (currently) support orgs. I did my best here to shim in the necessary code to account for that, but some extra attention here would be great.

Looks fine so far. Bitbucket also doesn't I think.

6543 · 2025-12-06T15:46:04Z

uuuuh :)

ddevault · 2025-12-06T16:03:34Z

uuuuh :)

Yes?

6543 · 2025-12-06T22:09:34Z

= nice will look into it once i have time :)
& happy to hear from sourcehut, had nice chat with sh guys at fosdem :)

ddevault · 2025-12-07T10:14:48Z

Oh, great :) I remember meeting you at FOSDEM, glad to be working together on this now.

qwerty287

Thanks! Added some comments to some of your points

qwerty287 · 2025-12-08T18:12:15Z

server/forge/sourcehut/sourcehut.go

+}
+
+func (c *SourceHut) PullRequests(ctx context.Context, u *model.User, r *model.Repo, p *model.ListOptions) ([]*model.PullRequest, error) {
+	return nil, nil // TODO


While this is right, changing this would probably add much complexity to the codebase. Having separate event handling for every forge would no longer allow us to let the UI define these labels, icons, etc. Also quite relevant features like the pull request gating is getting harder. Sure, it's possible, but I'm not sure if it's the right way to go (but I also don't know how complex that would be exactly).

About your first paragraph, can you elaborate some more here? Cause I don't know if I get that correctly. I never used sourcehut. Would it be possible to use the patches just (or mostly) like pull requests? Yes, there probably wouldn't be events like "pr closed" or "pr metadata updated". So the question mainly is if sourcehut can send a webhook linked to a repo if a patch comes in and if this patch can be cloned directly. If yes, this should work I think, if not, that would be hard to implement at woodpeckers side. And what do you mean by "separate UI"? A separate UI in woodpecker?

qwerty287 · 2025-12-08T18:13:17Z

server/forge/sourcehut/sourcehut.go

+		IsUser:  true,
+		Private: false,
+	}, nil
+}


Looks fine so far. Bitbucket also doesn't I think.

qwerty287 · 2025-12-08T18:16:35Z

server/forge/sourcehut/helper.go

+		c.gitURL, from.Repository.Owner.CanonicalName, from.Repository.Name,
+		update.New.Id)
+
+	return &model.Pipeline{


How much would that change the binary size? If it's not much we can add it I think.

ddevault · 2025-12-09T08:43:34Z

I think the CI failures are not entirely related to my work? Is that the case?

qwerty287 · 2025-12-09T12:12:35Z

They are related, the CI doesn't run go generate afaik as we commit all the generated files as well.

6543 · 2025-12-17T16:12:06Z

Thanks qwerty for step in, i currently did not have mouch time ... and the holydays are packed with dates ... 😓

ddevault commented Dec 6, 2025

View reviewed changes

ddevault force-pushed the push-qltmoytnsymr branch from 8a182db to 5cf085d Compare December 6, 2025 15:12

Implement SourceHut forge backend

c12a200

ddevault force-pushed the push-qltmoytnsymr branch from 5cf085d to c12a200 Compare December 6, 2025 15:19

qwerty287 added the feature add new functionality label Dec 8, 2025

qwerty287 reviewed Dec 8, 2025

View reviewed changes

Uh oh!

Implement SourceHut forge backend #5834

Are you sure you want to change the base?

Implement SourceHut forge backend #5834

Uh oh!

Conversation

ddevault commented Dec 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ddevault Dec 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

6543 commented Dec 6, 2025

Uh oh!

ddevault commented Dec 6, 2025

Uh oh!

6543 commented Dec 6, 2025

Uh oh!

ddevault commented Dec 7, 2025

Uh oh!

qwerty287 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ddevault commented Dec 9, 2025

Uh oh!

qwerty287 commented Dec 9, 2025

Uh oh!

6543 commented Dec 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ddevault Dec 6, 2025 •

edited

Loading

qwerty287 left a comment •

edited

Loading