Fixed issues with Build files for Android and Linux

.gitea/workflows/BuildAndroid.yml

@@ -89,9 +89,14 @@ jobs:
       - name: Name the apk after the release
         run: mv build/app/outputs/flutter-apk/app-release.apk ac_web-${{ github.ref_name }}.apk
 
-      # Artifacts of v4 need gitea 1.22 or newer, older instances need @v3.
+      # @v3 on purpose: `upload-artifact@v4` bundles `@actions/artifact` v2,
+      # which refuses to run as soon as `GITHUB_SERVER_URL` is not github.com
+      # ("GHESNotSupportedError") -- and on this instance it is the gitea host.
+      # The check happens in the action itself, before any request, so it
+      # cannot be fixed on the gitea side. @v3 talks to the older artifact api
+      # gitea implements and still runs on node20, which the act-runner allows.
       - name: Upload the apk
-        uses: https://github.com/actions/upload-artifact@v4
+        uses: https://github.com/actions/upload-artifact@v3
         with:
           name: ac_web-android-${{ github.ref_name }}
           # Artifact paths are relative to the repository, not to the

.gitea/workflows/BuildLinux.yml

@@ -72,9 +72,14 @@ jobs:
       - name: Pack the bundle
         run: tar -czf ac_web-linux-x64-${{ github.ref_name }}.tar.gz -C build/linux/x64/release bundle
 
-      # Artifacts of v4 need gitea 1.22 or newer, older instances need @v3.
+      # @v3 on purpose: `upload-artifact@v4` bundles `@actions/artifact` v2,
+      # which refuses to run as soon as `GITHUB_SERVER_URL` is not github.com
+      # ("GHESNotSupportedError") -- and on this instance it is the gitea host.
+      # The check happens in the action itself, before any request, so it
+      # cannot be fixed on the gitea side. @v3 talks to the older artifact api
+      # gitea implements and still runs on node20, which the act-runner allows.
       - name: Upload the bundle
-        uses: https://github.com/actions/upload-artifact@v4
+        uses: https://github.com/actions/upload-artifact@v3
         with:
           name: ac_web-linux-x64-${{ github.ref_name }}
           # Artifact paths are relative to the repository, not to the

CLAUDE.md

@@ -47,6 +47,7 @@ Notes that are easy to get wrong:
 - **The act-runner of the gitea instance only supports actions up to `node20`.** Anything newer fails with `The runs.using key in action.yml must be one of: [...], got node24`, which is why the Flutter sdk is unpacked from the official archive instead of through `subosito/flutter-action` (that one caches through `actions/cache@v5`). Check the `runs.using` of an action before adding it.
 - The Flutter version is pinned in three places (`FLUTTER_VERSION` in both build workflows, `ARG FLUTTER_VERSION` in `ac_web/Dockerfile`) and must be kept in sync.
 - Steps run with `working-directory: ac_web`, but `upload-artifact` paths are relative to the repository root.
+- **`actions/upload-artifact` must stay at `@v3`.** `@v4` bundles `@actions/artifact` v2, which aborts with `GHESNotSupportedError` whenever `GITHUB_SERVER_URL` is not `github.com` -- on this instance it is the gitea host, so the check fires before any request and cannot be worked around on the server side. `@v3` uses the older artifact api gitea implements.
 - The workflows are read from the tag the release points at, so they have to be committed **before** the release is created.
 - Artifacts and the built files carry the tag name (`github.ref_name`); the docker image is pushed as the tag, as `latest` and as the short sha.
 - The apk is signed with a debug key, because `android/app/build.gradle.kts` still has no release signing config.