making dummy PRs against my own fork doesn't help: https://github.com/timotheecour/Nim/pull/160 shows no builds.sr.ht being triggered even though they're triggered on the repo I forked as you can see here https://github.com/nim-lang/Nim/pull/14234

As far as I can tell, you don't have any tasks set up on https://dispatch.sr.ht anymore.

Note that by forking a GitHub repo you don't automatically inherit all of its dispatch hooks.

I'm pretty sure this worked until 14 days ago and I have't changed anything relevant; also I'm not seeing my nim fork in https://dispatch.sr.ht/github_pr_to_build/configure?search=timotheecour%2Fnim

has support for fork been removed recently?

Do you have any tasks shown on the dispatch.sr.ht home page?

I'm not sure how well forks have ever worked. We're pretty constrained by the GitHub API.

https://dispatch.sr.ht/ shows You haven't created any tasks yet. then i got to https://dispatch.sr.ht/configure and click configure task for GitHub pull requests builds.sr.ht jobs then i see https://dispatch.sr.ht/github_pr_to_build/configure a bunch of my github repos but not https://github.com/timotheecour/Nim (even if I search for nim via https://dispatch.sr.ht/github_pr_to_build/configure?search=Nim

And this definitely was working before

I wonder if this was caused by 5b1bb83b1454507e80336c4696df28170b9bb18d.

~kchibisov, what do you think?

actually I'm seeing 0 forks on that list

btw, what is the git repo url (or github mirror if it exists) for builds.sr.rt (that would contain 5b1bb83b1454507e80336c4696df28170b9bb18d ) ? I've asked here https://todo.sr.ht/~sircmpwn/builds.sr.ht/276#event-31402 but all I got was a "lol" ;-) (oh and super helpful for the prompt answers btw, thanks!)

builds.sr.ht is at https://git.sr.ht/~sircmpwn/builds.sr.ht

But this problem in truth belongs to dispatch.sr.ht, which is here: https://git.sr.ht/~sircmpwn/dispatch.sr.ht

You can find all of the source code here: https://sr.ht/~sircmpwn/sourcehut

You may just use builds.sr.ht via GitHub, but SourceHut is an entire code forge, not just some GitHub addon. It would not be couth for us to put our code there for "visibility". This is why I laughed at your suggestion.

thanks for the links! I totally stand by my assessment that the sources are really hard to find (even after you showed me the, it's hard to find starting from https://builds.sr.ht/; I could be missing something big and obvious, but I'm sure I'm not the only one)

judging from the small number of unique committers to https://git.sr.ht/~sircmpwn/dispatch.sr.ht git repo, I also do believe that improving visibility (in particular accepting github PR's on a git mirror) would do wonders in terms of increasing external contributions; same rationale as to why https://gitgitgadget.github.io/ exists (git repo doesn't accept github PR's so ppl created a way around that)

that being said, would this help fix this issue? https://github.com/timotheecour/dispatch.sr.ht/pull/1

I am not going to mirror it to GitHub, and frankly I find the suggestion offensive. We do not accept pull requests, and I have no intention of looking at yours. We use emails to facilitate collaboration, with well documented tooling, documentation, and tutorials, which you might encounter if you approached SourceHut on our terms rather than only looking at it insofar as it's necessary to get BSD CI for your GitHub project.

For a little bit of perspective, consider if someone told you this three times: "You'd probably get a lot more people contributing to the Nim compiler if it was written in a more compiler-friendly language like C++."

here's the suggested git format-patch master output since you don't want to open that link.

From 62207187fc56b1c9b850bb08575fe4d147fb60ad Mon Sep 17 00:00:00 2001
From: Timothee Cour <timothee.cour2@gmail.com>
Date: Tue, 5 May 2020 19:02:08 -0700
Subject: [PATCH] grant access to public repos

---
 dispatchsrht/tasks/github/common.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dispatchsrht/tasks/github/common.py b/dispatchsrht/tasks/github/common.py
index 5673d57..dcc8616 100644
--- a/dispatchsrht/tasks/github/common.py
+++ b/dispatchsrht/tasks/github/common.py
@@ -40,7 +40,7 @@ def github_redirect(return_to):
     # TODO: Do we want to generalize the scopes?
     parameters = {
         "client_id": _github_client_id,
-        "scope": "repo:status write:repo_hook user:email repo_deployment read:org",
+        "scope": "repo:status public_repo write:repo_hook user:email repo_deployment read:org",
         "state": return_to,
     }
     return redirect("{}?{}".format(gh_authorize_url, urlencode(parameters)))
--
2.26.0

We use emails to facilitate collaboration, with well documented tooling, documentation, and tutorials, which you might encounter if you approached SourceHut on our terms rather than only looking at it insofar as it's necessary to get BSD CI for your GitHub project.

that's fine, you may jut be missing out on external contributions from people accustomed to PRs and who would rather not have to go through tutorials before they can even send a patch.

I don't want the git format-patch output, either. Patches are accepted via email to sr.ht-dev. This is explained on the page I linked you to earlier. If you are unfamiliar with git via email, consult our tutorial here:

https://git-send-email.io

I would honestly expect better from the maintainers of a project like Nim. How would you feel if I emailed you a patch for Nim, and refused to use your GitHub tools?

I'm not a maintainer of Nim, I'm just trying to get builds.sr.ht CI to work with my nim fork like it used to so that I can debug a CI failure on openbsd for a nim PR, but this is leading me to an unexpectedly complex rabbit hole.

I wonder if this was caused by 5b1bb83b1454507e80336c4696df28170b9bb18d.

Well, if we take into account information about 14 days, the patch was way before this, like ~40 days ago, so it was running at least for near a month applied, before the mentioned breakage.

Also, I'd like to mention that travis is using the exact same scopes as a dispatch.sr.ht, so I don't think it needs more permissions, since the amount of permissions travis is using should be enough to do that. public_repo is a bit draconian access for CI, especially knowing that other CI's which are proven to work on forks can handle that.

However, it could be related to those checks

https://git.sr.ht/~sircmpwn/dispatch.sr.ht/tree/master/dispatchsrht/tasks/github/github_pr_to_build.py#L141 https://git.sr.ht/~sircmpwn/dispatch.sr.ht/tree/master/dispatchsrht/tasks/github/github_commit_to_build.py#L101

which has not fork. So testing a removal of it could be interesting.

EDIT: I'm now not sure forks ever worked, the olds builds I'm seeming in https://builds.sr.ht/ are all mentioned as "resubmission" so were perhaps only triggered via clicking on "resubmit build" in the original repo where I initiated a PR. The issue remains that forks should work without having to send a PR to original repo. So those not fork checks (there since 2018) could indeed be worth looking into to check if this would fix this

=> https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/10489

EDIT: I'm now not sure forks ever worked, the olds builds I'm seeming in https://builds.sr.ht/ are all mentioned as resubmission so were perhaps only triggered via clicking on resubmit build in the original repo where I initiated a PR.

This makes sense. Using "edit and resubmit" or just "resubmit" is the perscribed way to initiate your own builds based on an upstream. It's not necessary to set up a fork and rig it up with dispatch.sr.ht, which is rather involved, when you can just do this. SourceHut builds are not rigged 1:1 to a source repository like you see in platforms like Travis - in fact, you can submit builds with zero repositories. You also don't need to rig up something like dispatch.sr.ht to submit builds in the first place, I did this by just going to builds.sr.ht/submit and typing in the manifest.

SourceHut does not generally encourage the use of GitHub-style "forks", seeing them as an anti-feature which is designed more to encourage you to incorporate GitHub's centralization more deeply into your workflow than it is designed to speed up or simplify your workflow. We use a much more ad-hoc approach.

Regarding the problem of whether or not dispatch.sr.ht should be able to submit builds for GitHub forks, I followed up on the mailing list.