20250906064710

I migrated my website git repository from GitHub to the t/suki Forgejo instance as well as the website's hosting from GitHub Pages to Nearly Free Speech today. It's been a while since I've used Nearly Free Speech, and I'm happy to see that not much has changed; it's still as simple, low-cost, and no-fuss as usual.

Overall, the migration went smoothly. In order to upload my site to the server I had to use rsync manually:

rsync --delete --progress --archive _site/ nfs:

However, when updating my GitHub action workflow to be compatible with Forgejo so the automatic deployment could continue, I ran into an issue. This was the end of the workflow log:

LFS: Client error: https://git.tsuki.games/exodrifter/website.git/info/lfs/objects/ef67b49026709326771be3cc8ab935eac98f1aef5f653115dfe7e12af2c89be0 error: failed to fetch some objects from 'https://git.tsuki.games/exodrifter/website.git/info/lfs' ::remove-matcher owner=checkout-git:: ::error::The process '/usr/bin/git' failed with exit code 2

If I change the workflow to run Git LFS manually with trace debugging turned on...

     steps:
       - name: Checkout
         uses: actions/checkout@v4
         with:
           fetch-depth: 0
-          lfs: true
+          lfs: false
+      - name: Checkout LFS
+        run: |
+          git lfs install --local
+          GIT_TRACE=1 git lfs pull

...I see this:

04:08:35.512661 trace git-lfs: HTTP: GET https://git.tsuki.games/exodrifter/website.git/info/lfs/objects/7f8ab0ccab209af4b55c19ae6d7f39b61e876474b643a9236b5031185263e25e 04:08:35.524043 trace git-lfs: HTTP: 400

Sure enough, when I look at the nginx log, I see a ton of logs that look like this (ip address redacted):

x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "POST /exodrifter/website.git/info/lfs/objects/batch HTTP/2.0" 200 3644 "-" "git-lfs/3.7.0 (GitHub; linux amd64; go 1.24.4)"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "git-lfs/3.7.0 (GitHub; linux amd64; go 1.24.4)"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "git-lfs/3.7.0 (GitHub; linux amd64; go 1.24.4)"
x.x.x.x - x-access-token [06/Sep/2025:04:19:28 +0000] "-" 400 150 "-" "-"

After several hours of research and trial and error, I am unable to determine the cause of this problem. What's weird is that if I checkout the same container that the workflow is using and then try to clone the repository myself, the lfs file checkout works.

I did find one GitHub issue actions/checkout#1043 that looks very similar to my problem, but there's no useful information there.

I'm suspicious it's an nginx configuration issue, but I'm not sure how to figure out what exactly is wrong. The configuration only contains a minor modification to the one provided by SWAG to make it point to the right subdomain:

-    server_name forgejo.*;
+    server_name git.*;

I'm inclined to think that the SWAG configuration is correct, but if it isn't I would suspect that the action is doing authentication in a different way that isn't being passed correctly through nginx. I think I'll have to come back to this later.

content

meta