Gitea + Act Runner: (actions/checkout) failing when Gitea is configured with a subpath #14148

New Issue

GiteaMirror · 2025-11-02T11:04:23-06:00

GiteaMirror commented

2025-11-02 11:04:23 -06:00

Originally created by @Usual-Coder on GitHub (Feb 17, 2025).

Description

While the (actions) runner is fully functional "out-of-the-box" when Gitea is set "basically" (with its own/dedicated fqdn), it doesn't when Gitea is using a subpath (https://hostname.tld/sub/path/to/gitea ... unlike your demo site = why I could not reproduce it over there, as requested when creating an issue), as it may be when configured for some "special" context (ex.: Tailscale).

Searching for a lighter alternative to GitLab, I've been using Gitea for months in that context without a problem. Now I'm trying to enable runners features.

I have followed the docker compose variant of your docs (and checked against the provided example) to set it all = the configuration seems pretty straightforward + everything is set accordingly = added a runner in the compose file, setting the variable GITEA_INSTANCE_URL with the same value as the one used by gitea's container (aka ROOT_URL):

(...)
services:
  gitea:
    (...)
    environment:
      ROOT_URL: "https://hostname.tld/sub/path/to/gitea"
    (...)
    image: "gitea/gitea"
    (...)

  # Part added to docker-compose.yml
  runner:
    (...)
    environment:
      (...)
      GITEA_INSTANCE_URL: "https://hostname.tld/sub/path/to/gitea"
      GITEA_RUNNER_REGISTRATION_TOKEN: validtokenhere
      (...)
    image: gitea/act_runner
    (...)

To avoid extra complexity (aka something related to my real workflow), I'm gonna stick to filling this issue based on the Quickstart example ... which fails in the same way ... while trying to clone from the wrong URL = missing the subpath!

From step Check out repository code (aka the one using actions/checkout@v4):

(...)
Fetching the repository
  [command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +6862cbe1b72d4fd5d597280cfbf6065b6db9404e:refs/remotes/origin/main
  fatal: repository 'https://hostname.tld/owner/repo/' not found
  The process '/usr/bin/git' failed with exit code 128
  Waiting 17 seconds before trying again
(...)

Important

The url displayed in previous logs has been redacted without altering its structure: https://hostname.tld/owner/repo while https://hostname.tld/sub/path/to/gitea/owner/repo was expected = missing the sub/path/to/gitea

I didn't tweak anything + checked both configurations =

inside gitea container: ROOT_URL is correctly set in app.ini (otherwise Gitea wouldn't have worked in the past few months 😏)
inside runner container: data/.runner contains "address": "https://hostname.tld/sub/path/to/gitea"
= gitea continues to work without any other issue + runner is listed and can be triggered
= runner received the info (GITEA_INSTANCE_URL seems to be doing its job) about the subpath but is not using it when needed!!!

I tried:

playing with github-server-url (gitea-server-url too ... just in case ... but you're mirroring GitHub actions so I wasn't expecting much here) = ignored
concatenating everything as repository (using a variable as fixed instance URL + owner/repo) = error (not a valid repo obviously)

I'm sorry I don't have time to dig into gitea/act_runner sources. No matter what, your product is great ! Thanks for providing a qualitative alternative for a self-hosted solution 🙇

Gitea Version

1.23.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Ubuntu LTS

How are you running Gitea?

Docker (images with) compose

Database

None

Originally created by @Usual-Coder on GitHub (Feb 17, 2025). ### Description While the (actions) runner is fully functional "out-of-the-box" when Gitea is set "basically" (with its own/dedicated fqdn), it doesn't **when** Gitea is **using a subpath** (https://hostname.tld/sub/path/to/gitea ... **unlike your demo site** = why I could not reproduce it over there, as requested when creating an issue), as it may be when configured for some "special" context (ex.: Tailscale). Searching for a _lighter_ alternative to GitLab, I've been using Gitea for months in that context without a problem. Now I'm trying to enable runners features. I have followed the _docker compose_ variant of your docs (and checked against the provided [example](https://gitea.com/gitea/act_runner/src/branch/main/examples/docker-compose)) to set it all = the configuration seems pretty straightforward + everything is set accordingly = added a runner in the compose file, setting the variable `GITEA_INSTANCE_URL` with the same value as the one used by `gitea`'s container (aka `ROOT_URL`): ```yaml (...) services: gitea: (...) environment: ROOT_URL: "https://hostname.tld/sub/path/to/gitea" (...) image: "gitea/gitea" (...) # Part added to docker-compose.yml runner: (...) environment: (...) GITEA_INSTANCE_URL: "https://hostname.tld/sub/path/to/gitea" GITEA_RUNNER_REGISTRATION_TOKEN: validtokenhere (...) image: gitea/act_runner (...) ``` To avoid extra complexity (aka something related to my real workflow), I'm gonna stick to filling this issue based on the [Quickstart example](https://docs.gitea.com/usage/actions/quickstart#use-actions) ... which **fails** in the same way ... while **trying to clone from the wrong URL** = **missing the subpath**! From step `Check out repository code` (aka the one using `actions/checkout@v4`): ``` (...) Fetching the repository [command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +6862cbe1b72d4fd5d597280cfbf6065b6db9404e:refs/remotes/origin/main fatal: repository 'https://hostname.tld/owner/repo/' not found The process '/usr/bin/git' failed with exit code 128 Waiting 17 seconds before trying again (...) ``` > [!IMPORTANT] > The url displayed in previous logs has been redacted without altering its structure: `https://hostname.tld/owner/repo` while `https://hostname.tld/`**`sub/path/to/gitea`**`/owner/repo` was expected = missing the **`sub/path/to/gitea`** I didn't _tweak_ anything + checked both configurations = - inside `gitea` container: `ROOT_URL` is correctly set in `app.ini` (otherwise Gitea wouldn't have worked in the past few months 😏) - inside `runner` container: `data/.runner` contains `"address": "https://hostname.tld/sub/path/to/gitea"` = `gitea` continues to work without any other issue + runner is listed and can be triggered = **`runner` received the info** (`GITEA_INSTANCE_URL` seems to be doing its job) **about the subpath but is not using it when needed!!!** I tried: - _playing with_ [`github-server-url`](https://gitea.com/actions/checkout#usage) (`gitea-server-url` too ... just in case ... but you're mirroring GitHub actions so I wasn't expecting much here) = **ignored** - concatenating everything as `repository` (using a variable as fixed instance URL + owner/repo) = **error** (not a valid repo obviously) I'm sorry I don't have time to dig into gitea/act_runner sources. No matter what, your product is great ! Thanks for providing a qualitative alternative for a self-hosted solution 🙇 ### Gitea Version 1.23.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Ubuntu LTS ### How are you running Gitea? Docker (images with) compose ### Database None

GiteaMirror added the type/bug label 2025-11-02 11:04:23 -06:00

GiteaMirror closed this issue

2025-11-02 11:04:23 -06:00

GiteaMirror commented

2025-11-02 11:04:24 -06:00

@Usual-Coder commented on GitHub (Feb 18, 2025):

In the meantime, as a temporary workaround, I have set additional DNS features (outside the scope of Gitea) to make my specific context (Tailscale) able to use subdomains instead of subpaths + I've reconfigured that very same instance accordingly = I reran the previous/old job (= without any change to it) ... successfully = QED!

I only updated "DNS related" parameters in Gitea's configuration and everything started clicking and working together like a charm = subpaths are obviously not handled correctly ... or at least require additional configuration/documentation?!

Note

I didn't doubt Gitea featuring actions runner was not functional at all (I already had tested it on other instances provisioned with the -easiest but sometimes unavailable- subdomain approach) = the issue would probably have been raised sooner otherwise 😏 ... I'm just demonstrating there was nothing wrong "somewhere else" with that/my instance = aka related to my specific context (Tailscale) = this issue may affect anyone using subpaths?!

Respectfully.

@Usual-Coder commented on GitHub (Feb 18, 2025): In the meantime, as a temporary workaround, I have set additional DNS features (outside the scope of Gitea) to make my specific context (Tailscale) able to use subdomains instead of subpaths + I've reconfigured that very same instance accordingly = I reran the previous/old job (= **without any change to it**) ... successfully = QED! I only updated "_DNS related_" parameters in Gitea's configuration and everything started _clicking_ and working together like a charm = **subpaths are obviously not handled correctly** ... or at least require additional configuration/documentation?! > [!NOTE] > I didn't doubt Gitea featuring actions runner was not functional at all (I already had tested it on other instances provisioned with the -**easiest but sometimes unavailable**- subdomain approach) = the issue would probably have been raised sooner otherwise 😏 ... I'm just _demonstrating_ there was nothing wrong "somewhere else" with that/my instance = aka related to my specific context (Tailscale) = this issue may affect anyone using subpaths?! Respectfully.

GiteaMirror commented

2025-11-02 11:04:24 -06:00

@wxiaoguang commented on GitHub (Feb 19, 2025):

IIRC many GitHub actions just are not able to work with sub-path (to be honest, it's not Gitea's problem ....)

So if you'd like to use Actions, then sub-path should be avoided.

(There are also other issues mentioning the same sub-path problem, I just can't find them at the moment).

@wxiaoguang commented on GitHub (Feb 19, 2025): IIRC many GitHub actions just are not able to work with sub-path (to be honest, it's not Gitea's problem ....) So if you'd like to use Actions, then sub-path should be avoided. (There are also other issues mentioning the same sub-path problem, I just can't find them at the moment).

GiteaMirror commented

2025-11-02 11:04:24 -06:00

@Usual-Coder commented on GitHub (Feb 20, 2025):

Hi,

As I see the Contributor tag on your answer, I'm gonna assume your position stands as the closest thing I'll have to an official one.

That being said, I can handle the hurdle of setting DNS stuff to avoid using subpaths ... which can be the easiest way for some contexts ... not sure everyone can do it ... or if it's even feasible for every context.

But I hear you ... not Gitea's problem. Point taken.

May I suggest adding a note/warning/whatev somewhere in the docs about that limitation ... to avoid similar issues as you're pointing them?!

Thanks for your answer anyway.

Respectfully.

@Usual-Coder commented on GitHub (Feb 20, 2025): Hi, As I see the `Contributor` tag on your answer, I'm gonna assume your position stands as the closest thing I'll have to an _official_ one. That being said, I can handle the hurdle of setting DNS stuff to avoid using subpaths ... which can be the easiest way for some contexts ... not sure everyone can do it ... or if it's even feasible for every context. But I hear you ... not Gitea's problem. Point taken. May I suggest adding a note/warning/whatev somewhere in the docs about that limitation ... to avoid similar issues as you're pointing them?! Thanks for your answer anyway. Respectfully.

GiteaMirror commented

2025-11-02 11:04:24 -06:00

@wxiaoguang commented on GitHub (Feb 20, 2025):

Hmm, thank you for your trust and consider it as "official one" 😆 I can't guarantee I am 100% correct but the situation is just like that in my opinion. The Actions ecosystem is quite complex.

May I suggest adding a note/warning/whatev somewhere in the docs about that limitation ... to avoid similar issues as you're pointing them?!

I agree, it's better to document it ......

@wxiaoguang commented on GitHub (Feb 20, 2025): Hmm, thank you for your trust and consider it as "official one" 😆 I can't guarantee I am 100% correct but the situation is just like that in my opinion. The Actions ecosystem is quite complex. ---- > May I suggest adding a note/warning/whatev somewhere in the docs about that limitation ... to avoid similar issues as you're pointing them?! I agree, it's better to document it ......

GiteaMirror commented

2025-11-02 11:04:25 -06:00

@Usual-Coder commented on GitHub (Feb 21, 2025):

Actions (runners) are not that complex, but it obviously takes time/bandwidth to get it right = I understand priorities/constraints/roadmaps/etc. ... I'm less understanding with the lack of (even minimal) documentation (aka warning at least) = you (Gitea devs/contrib/whoever is in the loop) don't want/have time for that ... that's more than OK/understandable (still a big thank you for providing this great alternative to the community) ... but don't make others waste theirs either + they won't bother you with (new) issues related to that (at least for those showing the minimum respect of reading what you've already put out there before filling a new issue) = consuming that precious (for everyone) time/bandwidth in the process ... just my 2 cents?!

As always, RTFM ~~should be~~ is the way ... on Mandalore ... and ... soon enough ... in this part of the Galaxy 😏

A specific warning (basically "Runners don't support Gitea instance configured under a subpath") at the end of https://docs.gitea.com/usage/actions/overview#status ... would have done the trick for me (and probably may do it for a few other profiles like mine, respecting religiously that RTFM motto) = I wouldn't have wasted my time (and yours?!) triple-checking everything / reading others issues/forums... and filling this issue!

For now, I don't have (that precious) time to contribute to the actions part (or any part of Gitea btw ... my Go being more rusty than anything) ... and I don't think I'll find it to read the rules / digest the contributing process, just to add that remark = I probably won't make a PR ... but if you're willing to add that in one of yours ... some people may be thankful for the time they won't waste on that matter 🤷 Thanks for considering it 🙇

Respectfully.

@Usual-Coder commented on GitHub (Feb 21, 2025): `Actions` (runners) are not _that_ complex, but it obviously takes time/_bandwidth_ to get it right = I understand priorities/constraints/roadmaps/etc. ... I'm less understanding with the lack of (even minimal) documentation (aka warning at least) = you (Gitea devs/contrib/whoever is _in the loop_) don't want/have time for that ... that's more than OK/understandable (still a big thank you for providing this great alternative to the community) ... but don't make others waste theirs either + they won't bother you with (new) issues related to that (at least for those showing the minimum respect of reading what you've already put out there before filling a new issue) = consuming that precious (for everyone) time/_bandwidth_ in the process ... just my 2 cents?! As always, RTFM ~~should be~~ is the way ... on Mandalore ... and ... soon enough ... in this part of the Galaxy 😏 A specific warning (basically "_**Runners don't support Gitea instance configured under a subpath**_") at the end of https://docs.gitea.com/usage/actions/overview#status ... would have done the trick for me (and probably may do it for a few other profiles like mine, respecting religiously that RTFM motto) = I wouldn't have wasted my time (and yours?!) triple-checking everything / reading others issues/forums... and filling this issue! For now, I don't have (that precious) time to contribute to the `actions` part (or any part of Gitea btw ... my Go being more rusty than anything) ... and I don't think I'll find it to read the _rules_ / _digest_ the contributing process, just to add that remark = I probably won't make a PR ... but if you're willing to add that in one of yours ... some people may be thankful for the time they won't waste on that matter 🤷 Thanks for considering it 🙇 Respectfully.

GiteaMirror commented

2025-11-02 11:04:25 -06:00

@TheFox0x7 commented on GitHub (Feb 21, 2025):

To chime in on the matter a bit, this is and isn't an issue with Gitea:
It is because by adopting GH actions the average user will expect them to work out of the box with Gitea - after all docs say:

It is similar and compatible to GitHub Actions

Which will lead to issues with their Gitea deployment not being what actions ecosystem expects or wants to support.

On the other hand it isn't. Gitea is working as intended and bug is in actions/checkout which you run - see: https://github.com/actions/checkout/issues/1242. To spare you a click and some reading - it's a won't fix as it's a GitHub ecosystem which works with GitHub and they ultimately have no reason to fix it (no, PR was not accepted).

There's nothing Gitea can do about this, short of forking checkout and maintaining it for Gitea.

Also statement such as:

"Runners don't support Gitea instance configured under a subpath"

is inaccurate. Runners support Gitea under subpath (if they did not, you wouldn't have ran the checkout action at all). It's the actions/checkout that doesn't support it. There's no telling how many actions do or do not support particular configuration.
I guess we can add another warning on top of sha256 repos one. If you want to, you can make a PR for it in docs repository.

I suggest closing this and opening an issue in docs for a warning.

@TheFox0x7 commented on GitHub (Feb 21, 2025): To chime in on the matter a bit, this is and isn't an issue with Gitea: It is because by adopting GH actions the average user will expect them to work out of the box with Gitea - after all docs say: > It is similar and compatible to GitHub Actions Which will lead to issues with their Gitea deployment not being what actions ecosystem expects or wants to support. On the other hand it isn't. Gitea is working as intended and bug is in actions/checkout which you run - see: https://github.com/actions/checkout/issues/1242. To spare you a click and some reading - it's a `won't fix` as it's a GitHub ecosystem which works with GitHub and they ultimately have no reason to fix it (no, PR was not accepted). There's nothing Gitea can do about this, short of forking checkout and maintaining it for Gitea. --- Also statement such as: > "Runners don't support Gitea instance configured under a subpath" is inaccurate. Runners support Gitea under subpath (if they did not, you wouldn't have ran the checkout action at all). It's the actions/checkout that doesn't support it. There's no telling how many actions do or do not support particular configuration. I guess we can add another warning on top of [sha256 repos one](https://docs.gitea.com/usage/actions/quickstart#use-actions). If you want to, [you can make a PR for it in docs repository](https://gitea.com/gitea/docs). I suggest closing this and opening an issue in docs for a warning.

GiteaMirror commented

2025-11-02 11:04:25 -06:00

@Usual-Coder commented on GitHub (Feb 21, 2025):

You' right. Closing it.

@Usual-Coder commented on GitHub (Feb 21, 2025): You' right. Closing it.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14148