Runners cannot fetch custom actions if DISABLE_HTTP_GIT/REQUIRE_SIGNIN_VIEW are both enabled

[lautriva]

Description

Gitea is running with following options (other settings and sections are present in app.ini but removed here for clarity)

DEFAULT_ACTIONS_URL = self
DISABLE_HTTP_GIT = true
REQUIRE_SIGNIN_VIEW = true

I don't use HTTP GIT, and as its a private instance I don't want public access

In the action, the "set up job" step fails with message: Unable to clone https://gitea.example.com/actions/my-custom-action refs/heads/master: authorization failed

Here is the test workflow

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/my-custom-action@master

Is it possible to use self-hosted actions in a private instance + SSH Git only? Or should I need to activate both options?

Gitea Version

1.20.5

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker compose

Database

MySQL/MariaDB

[lunny]

I think it's mostly affected by DISABLE_HTTP_GIT. This is an item conflicted with Actions runner because actions/checkout needs to clone the repository with HTTP GIT protocol.

[ItsJustRuby]

I think it's mostly affected by DISABLE_HTTP_GIT. This is an item conflicted with Actions runner because actions/checkout needs to clone the repository with HTTP GIT protocol.

I am affected by this issue as well without customizing DISABLE_HTTP_GIT from the default (false). I have reproduced this issue locally down to toggling REQUIRE_SIGNIN_VIEW between

• false (runner succeeds at pulling the action) and
• true (runner fails immediately upon trying to pull the action)

[inta]

I can confirm that cloning of actions fails if DEFAULT_ACTIONS_URL is self and REQUIRE_SIGNIN_VIEW is set to true. It seems like actions can only be cloned from public repos without authentication. Getting them from the local Gitea instance should be possible I think, it's somehow unexpected that it doesn't.

  ☁  git clone 'https://code.example.com/actions/my-action' # ref=v4.5
  cloning https://code.example.com/actions/my-action to /home/runner/.cache/act/actions-my-action@v4.5
Unable to clone https://code.example.com/actions/my-action refs/heads/v4.5: authentication required
authentication required

[jtran]

Can this be labeled "topic/gitea-actions"? Thanks.

[shootie22]

Is there a known fix for this? I'm running into the same issue.

[mpeter50]

This issue is also present in Gitea v1.22.1 with act runner v0.2.10.

On this server DISABLE_HTTP_GIT has not been customized, so it should have the default value of false, but REQUIRE_SIGNIN_VIEW has been set to true. Besides that, I have found that if the organization visibility of the action repo is not public, but e.g. limited, that also results in the same error message when the job attempts to pull the action repo, even when REQUIRE_SIGNIN_VIEW is set to false.

[mpeter50]

@shootie22 allowing the action repo to be accessed without authentication, by having REQUIRE_SIGNIN_VIEW as false, the org as public and the repo as not being private makes it work, but thats just a workaround, and maybe you cant afford to do that.

I'm not happy either that I have to disable these restrictions, but after thinking about it, the "limited" visibility seems to just be a fine tuned version of REQUIRE_SIGNIN_VIEW, and if thats right then it might be less of a problem to disable REQUIRE_SIGNIN_VIEW, while also setting most of your orgs to limited visibility, as well as all of your users to limited visibility. Each of them can do that in the profile settings, but an admin can set it for everyone at the /admin/users subpage.

[mpeter50]

Btw, according to the docs, it seems to me that the current behavior is by design:

Runners have no more permissions than simply connecting to your Gitea instance.

But, thats not to say it cant be improved upon.

[Philogag]

In my personal opinion, the fact that the act runner needs a token which provide by someone already registed to access the gitea instance, means that it's already part of the invitees. It should be able to have public access to the gitea instance exactly as the logged-in user has it.