go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
43.82k stars 5.38k forks source link

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

Open lautriva opened 9 months ago

lautriva commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

inta commented 7 months ago

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 commented 4 months ago

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

shootie22 commented 3 months ago

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

mpeter50 commented 3 weeks ago

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 commented 3 weeks ago

@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 commented 3 weeks ago

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.