actions: login via GITEA_TOKEN to package repository not working #10484

@KN4CK3R commented on GitHub (Mar 24, 2023):

Just a note: That looks like it works but you can't upload a container or other things.

@KN4CK3R commented on GitHub (Mar 24, 2023): Just a note: That looks like it works but you can't upload a container or other things.

GiteaMirror commented

@philkunz commented on GitHub (Jun 26, 2023):

What is the status on this one?

@philkunz commented on GitHub (Jun 26, 2023): What is the status on this one?

GiteaMirror commented

@lunny commented on GitHub (Jun 26, 2023):

It depends on the trigger user's permission to that package. And you can always use a PAT to do that.

@lunny commented on GitHub (Jun 26, 2023): It depends on the trigger user's permission to that package. And you can always use a PAT to do that.

GiteaMirror commented

@philkunz commented on GitHub (Jun 26, 2023):

Ok, but 1.19.3 still does not pay respect to that, or? Because the build happens on push through me, I'm the owner of the repo and it still fails with authentication required after using GITEA_TOKEN for a successful Docker Login.

Which is the earliest version that works?

@philkunz commented on GitHub (Jun 26, 2023): Ok, but 1.19.3 still does not pay respect to that, or? Because the build happens on push through me, I'm the owner of the repo and it still fails with authentication required after using GITEA_TOKEN for a successful Docker Login. Which is the earliest version that works?

GiteaMirror commented

@KN4CK3R commented on GitHub (Jun 26, 2023):

The linked PR is active with 1.20

@KN4CK3R commented on GitHub (Jun 26, 2023): The linked PR is active with 1.20

GiteaMirror commented

@AndyTempel commented on GitHub (Jul 2, 2023):

Currently on 1.20.0-rc2 and this works:

- name: Log in to the Container registry
  uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
  with:
      registry: git.example.com
      username: ${{ gitea.repository_owner }}
      password: ${{ secrets.GITEA_TOKEN}}

But push fails with:
docker/build-push-action@2eb1c1961a95fc15694676618e422e8ba1d63825

#28 [auth] *:: project/app:pull,push token for git.example.com
#28 DONE 0.0s
#29 [auth] sharing credentials for git.example.com
#29 DONE 0.0s
#27 exporting to image
#27 pushing layers 1.0s done
#27 ERROR: failed to push git.example.com/project/app:master: unexpected status: 401 Unauthorized
------
 > exporting to image:
------
ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized
::error::buildx failed with: ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized

@AndyTempel commented on GitHub (Jul 2, 2023): Currently on 1.20.0-rc2 and this works: ```yml - name: Log in to the Container registry uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1 with: registry: git.example.com username: ${{ gitea.repository_owner }} password: ${{ secrets.GITEA_TOKEN}} ``` But push fails with: `docker/build-push-action@2eb1c1961a95fc15694676618e422e8ba1d63825` ``` #28 [auth] *:: project/app:pull,push token for git.example.com #28 DONE 0.0s #29 [auth] sharing credentials for git.example.com #29 DONE 0.0s #27 exporting to image #27 pushing layers 1.0s done #27 ERROR: failed to push git.example.com/project/app:master: unexpected status: 401 Unauthorized ------ > exporting to image: ------ ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized ::error::buildx failed with: ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized ```

GiteaMirror commented

@krombel commented on GitHub (Jul 3, 2023):

That is right as @KN4CK3R mentioned before: https://github.com/go-gitea/gitea/issues/23642#issuecomment-1482584036

Here it got decided to temporarily only allow read only access and postpone the permission check: https://github.com/go-gitea/gitea/pull/23729#issuecomment-1492774010

The underlining issue is an ongoing discussion how to manage permissions in general. There is a proposal in https://github.com/go-gitea/gitea/issues/24635 but nothing implemented in that direction yet (AFAIK)

@krombel commented on GitHub (Jul 3, 2023): That is right as @KN4CK3R mentioned before: https://github.com/go-gitea/gitea/issues/23642#issuecomment-1482584036 Here it got decided to temporarily only allow read only access and postpone the permission check: https://github.com/go-gitea/gitea/pull/23729#issuecomment-1492774010 The underlining issue is an ongoing discussion how to manage permissions in general. There is a proposal in https://github.com/go-gitea/gitea/issues/24635 but nothing implemented in that direction yet (AFAIK)

GiteaMirror commented

@sgabenov commented on GitHub (Sep 18, 2023):

You can try to specify token within url

      - name: Delete git repository old branches
        uses: https://${{ secrets.GIT_ACCESS_TOKEN }}:@gitea.my.domain/emb_tools/gitea-actions-delete-abandoned-branches@v1
        id: delete_stuff

@sgabenov commented on GitHub (Sep 18, 2023): You can try to specify token within url ``` - name: Delete git repository old branches uses: https://${{ secrets.GIT_ACCESS_TOKEN }}:@gitea.my.domain/emb_tools/gitea-actions-delete-abandoned-branches@v1 id: delete_stuff ```

GiteaMirror commented

2025-11-02 09:08:56 -06:00

@PatrickHuetter commented on GitHub (Sep 29, 2023):

Currently on 1.20.0-rc2 and this works:

- name: Log in to the Container registry
  uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
  with:
      registry: git.example.com
      username: ${{ gitea.repository_owner }}
      password: ${{ secrets.GITEA_TOKEN}}

But push fails with: docker/build-push-action@2eb1c1961a95fc15694676618e422e8ba1d63825

#28 [auth] *:: project/app:pull,push token for git.example.com
#28 DONE 0.0s
#29 [auth] sharing credentials for git.example.com
#29 DONE 0.0s
#27 exporting to image
#27 pushing layers 1.0s done
#27 ERROR: failed to push git.example.com/project/app:master: unexpected status: 401 Unauthorized
------
 > exporting to image:
------
ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized
::error::buildx failed with: ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized

Same result for me with gitea 1.20.4. How do you push the docker images to the gitea container registry from within the gitea actions? Do you use custom PATs instead the GITEA_TOKEN/GITHUB_TOKEN?

@PatrickHuetter commented on GitHub (Sep 29, 2023): > Currently on 1.20.0-rc2 and this works: > > ```yaml > - name: Log in to the Container registry > uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1 > with: > registry: git.example.com > username: ${{ gitea.repository_owner }} > password: ${{ secrets.GITEA_TOKEN}} > ``` > > But push fails with: `docker/build-push-action@2eb1c1961a95fc15694676618e422e8ba1d63825` > > ``` > #28 [auth] *:: project/app:pull,push token for git.example.com > #28 DONE 0.0s > #29 [auth] sharing credentials for git.example.com > #29 DONE 0.0s > #27 exporting to image > #27 pushing layers 1.0s done > #27 ERROR: failed to push git.example.com/project/app:master: unexpected status: 401 Unauthorized > ------ > > exporting to image: > ------ > ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized > ::error::buildx failed with: ERROR: failed to solve: failed to push git.example.com/project/app:master:master: unexpected status: 401 Unauthorized > ``` Same result for me with gitea 1.20.4. How do you push the docker images to the gitea container registry from within the gitea actions? Do you use custom PATs instead the GITEA_TOKEN/GITHUB_TOKEN?

GiteaMirror commented

@krombel commented on GitHub (Sep 29, 2023):

@PatrickHuetter You must use PATs for writing to package repositories right now.
As mentioned in my comment before there is no implementation yet - not in master and therefore in no release either - to use GIT{EA,HUB}_TOKEN for pushing to package repositories.

@krombel commented on GitHub (Sep 29, 2023): @PatrickHuetter You must use PATs for writing to package repositories right now. As mentioned in [my comment before](https://github.com/go-gitea/gitea/issues/23642#issuecomment-1618060319) there is no implementation yet - not in master and therefore in no release either - to use GIT{EA,HUB}_TOKEN for pushing to package repositories.

GiteaMirror commented

2025-11-02 09:08:56 -06:00

@PatrickHuetter commented on GitHub (Sep 29, 2023):

@PatrickHuetter You must use PATs for writing to package repositories right now. As mentioned in my comment before there is no implementation yet - not in master and therefore in no release either - to use GIT{EA,HUB}_TOKEN for pushing to package repositories.

Thanks @krombel. I got it working with PATs.

@PatrickHuetter commented on GitHub (Sep 29, 2023): > @PatrickHuetter You must use PATs for writing to package repositories right now. As mentioned in [my comment before](https://github.com/go-gitea/gitea/issues/23642#issuecomment-1618060319) there is no implementation yet - not in master and therefore in no release either - to use GIT{EA,HUB}_TOKEN for pushing to package repositories. Thanks @krombel. I got it working with PATs.

GiteaMirror commented

2025-11-02 09:08:56 -06:00

@the-maldridge commented on GitHub (Mar 1, 2024):

This should be listed as a missing feature on this page. My organization does not permit static PATs to be used in workflows, which means we can't use that as a workaround. It would have been much easier to figure out this is why the permissions error occurs if it had been listed in the documentation as a current limitation.

@the-maldridge commented on GitHub (Mar 1, 2024): This should be listed as a missing feature on [this page](https://docs.gitea.com/usage/actions/comparison#missing-features). My organization does not permit static PATs to be used in workflows, which means we can't use that as a workaround. It would have been much easier to figure out this is why the permissions error occurs if it had been listed in the documentation as a current limitation.

GiteaMirror commented

@Elbandi commented on GitHub (Apr 6, 2024):

it doesnt work for me with user PAT:

docker login git.domain.hu -u jenkins -p 3132131231231232
docker push git.domain.hu/elbandi/test

i added some debug logs:

2024/04/06 20:56:30 ...es/container/auth.go:31:Verify() [I] uid: 7
2024/04/06 20:56:30 ...es/container/auth.go:37:Verify() [I] GetPossibleUserByID() u:<User 7:jenkins>
2024/04/06 20:56:30 ...es/container/auth.go:37:Verify() [I] GetPossibleUserByID() u:<User 7:jenkins>
2024/04/06 20:56:30 .../api/packages/api.go:44:func5() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil>
2024/04/06 20:56:30 .../api/packages/api.go:44:func4() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil>
2024/04/06 20:56:30 .../api/packages/api.go:44:func5() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil>
2024/04/06 20:56:30 .../api/packages/api.go:44:func4() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil>
2024/04/06 20:56:30 ...eb/routing/logger.go:102:func1() [I] router: completed POST /v2/elbandi/test/blobs/uploads/ for 192.168.200.40:0, 401 Unauthorized in 1.2ms @ packages/api.go:43(packages.ContainerRoutes.func2.1.reqPackageAccess)

So looks like container.Verify() found the right user, but doesnt fill the IsApiToken and ApiTokenScope data fields. therefore reqPackageAccess denied the access.

Gitea version: 1.21.10 built with GNU Make 4.2.1, go1.21.9 : bindata, sqlite, sqlite_unlock_notify

@Elbandi commented on GitHub (Apr 6, 2024): it doesnt work for me with user PAT: ``` docker login git.domain.hu -u jenkins -p 3132131231231232 docker push git.domain.hu/elbandi/test ``` i added some debug logs: ``` 2024/04/06 20:56:30 ...es/container/auth.go:31:Verify() [I] uid: 7 2024/04/06 20:56:30 ...es/container/auth.go:37:Verify() [I] GetPossibleUserByID() u:<User 7:jenkins> 2024/04/06 20:56:30 ...es/container/auth.go:37:Verify() [I] GetPossibleUserByID() u:<User 7:jenkins> 2024/04/06 20:56:30 .../api/packages/api.go:44:func5() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil> 2024/04/06 20:56:30 .../api/packages/api.go:44:func4() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil> 2024/04/06 20:56:30 .../api/packages/api.go:44:func5() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil> 2024/04/06 20:56:30 .../api/packages/api.go:44:func4() [I] reqPackageAccess: Data["IsApiToken"]: <nil>, Data["ApiTokenScope"]: <nil> 2024/04/06 20:56:30 ...eb/routing/logger.go:102:func1() [I] router: completed POST /v2/elbandi/test/blobs/uploads/ for 192.168.200.40:0, 401 Unauthorized in 1.2ms @ packages/api.go:43(packages.ContainerRoutes.func2.1.reqPackageAccess) ``` So looks like container.Verify() found the right user, but doesnt fill the IsApiToken and ApiTokenScope data fields. therefore reqPackageAccess denied the access. Gitea version: 1.21.10 built with GNU Make 4.2.1, go1.21.9 : bindata, sqlite, sqlite_unlock_notify

GiteaMirror commented

@lunny commented on GitHub (Apr 7, 2024):

docker login

I cannot reproduce this. Please check your PAT's permission which has read/write packages permission.

@lunny commented on GitHub (Apr 7, 2024): > docker login I cannot reproduce this. Please check your PAT's permission which has read/write packages permission.

GiteaMirror commented

@Elbandi commented on GitHub (Apr 7, 2024):

docker login

I cannot reproduce this. Please check your PAT's permission which has read/write packages permission.

scope: all, and "jenkins" user is added to project with write permission.
(ofc just for testing)

@Elbandi commented on GitHub (Apr 7, 2024): > > docker login > > I cannot reproduce this. Please check your PAT's permission which has read/write packages permission. scope: all, and "jenkins" user is added to project with write permission. (ofc just for testing)

GiteaMirror commented

@lunny commented on GitHub (Apr 8, 2024):

You still need to choose the permissions after choosing ALL in the UI. ALL means all of the repositories which don't mean permissions.

@lunny commented on GitHub (Apr 8, 2024): You still need to choose the permissions after choosing ALL in the UI. ALL means all of the repositories which don't mean permissions. <img width="1026" alt="image" src="https://github.com/go-gitea/gitea/assets/81045/dcce62c1-529d-4e58-a122-b6e651fbe2e4">

GiteaMirror commented

@Elbandi commented on GitHub (Apr 10, 2024):

You still need to choose the permissions after choosing ALL in the UI. ALL means all of the repositories which don't mean permissions.

As i said, all permissions are added. i listed the tokes by api:

 GET /api/v1/users/jenkins/tokens

Response:

 [
  {
    "id": 8,
    "name": "runner",
    "sha1": "",
    "token_last_eight": "bf14d900",
    "scopes": [
      "all"
    ]
  }
]

@Elbandi commented on GitHub (Apr 10, 2024): > You still need to choose the permissions after choosing ALL in the UI. ALL means all of the repositories which don't mean permissions. > As i said, all permissions are added. i listed the tokes by api: GET /api/v1/users/jenkins/tokens Response: [ { "id": 8, "name": "runner", "sha1": "", "token_last_eight": "bf14d900", "scopes": [ "all" ] } ]

GiteaMirror commented

@yp05327 commented on GitHub (Apr 11, 2024):

If the owner of this repo is organization, does this user have the permission to access organization packages?

@yp05327 commented on GitHub (Apr 11, 2024): If the owner of this repo is organization, does this user have the permission to access organization packages?

GiteaMirror commented

@KN4CK3R commented on GitHub (May 14, 2024):

I don't think this is implemented. The job token can't be used to publish packages at the moment.

@KN4CK3R commented on GitHub (May 14, 2024): I don't think this is implemented. The job token can't be used to publish packages at the moment.

GiteaMirror commented

@Elbandi commented on GitHub (May 18, 2024):

It look like, token is not working for personal repo (eg: elbandi/test)
Here, i create a new token for jenkins user with full access:

$ sudo -u git /usr/local/sbin/gitea admin user generate-access-token --username jenkins --token-name testtoken --scopes "all"
Access token was successfully created: 2bcb4b4293d6f624b49d22cd8f8f46b800c65cc5

I verify, that jenkins user has write permission to elbandi/test:

curl -X 'GET' \
  'https://git.domain.hu/api/v1/repos/elbandi/test/collaborators/jenkins/permission' \
  -H 'accept: application/json' \
  -H 'authorization: Basic xxxx'

result (look good: jenkins has write role to elbandi/test):

{
  "permission": "write",
  "role_name": "write",
  "user": {
    "id": 7,
    "login": "jenkins",
    "login_name": "",
    "full_name": "Jenkins build system",
    "email": "jenkins@domain.hu",
    "language": "",
    "is_admin": false,
    "last_login": "1970-01-01T01:00:00+01:00",
    "created": "2021-03-03T00:07:56+01:00",
    "restricted": false,
    "active": true,
    "prohibit_login": false,
    "location": "",
    "website": "",
    "description": "",
    "visibility": "public",
    "followers_count": 0,
    "following_count": 0,
    "starred_repos_count": 0,
    "username": "jenkins"
  }
}

Try to upload a file as a generic package to elbandi/test:

$ curl --user jenkins:2bcb4b4293d6f624b49d22cdbf8f46b800c65cc5 \
 --upload-file README.md \
 https://git.elbandi.net/api/packages/elbandi/generic/test/1.0.0/file.bin
reqPackageAccess
$

unsuccessful :(

Try to upload a file as a generic package to an organisation package:

$ curl --user jenkins:2bcb4b4293d6f624b49d22cdbf8f46b800c65cc5 \
  --upload-file README.md \
  https://git.elbandi.net/api/packages/kubernetes/generic/test/1.0.0/file.bin
$

it works.

@Elbandi commented on GitHub (May 18, 2024): It look like, token is not working for personal repo (eg: elbandi/test) Here, i create a new token for jenkins user with full access: $ sudo -u git /usr/local/sbin/gitea admin user generate-access-token --username jenkins --token-name testtoken --scopes "all" Access token was successfully created: 2bcb4b4293d6f624b49d22cd8f8f46b800c65cc5 I verify, that jenkins user has write permission to elbandi/test: ```shell curl -X 'GET' \ 'https://git.domain.hu/api/v1/repos/elbandi/test/collaborators/jenkins/permission' \ -H 'accept: application/json' \ -H 'authorization: Basic xxxx' ``` result (look good: jenkins has write role to elbandi/test): ```jsonnet { "permission": "write", "role_name": "write", "user": { "id": 7, "login": "jenkins", "login_name": "", "full_name": "Jenkins build system", "email": "jenkins@domain.hu", "language": "", "is_admin": false, "last_login": "1970-01-01T01:00:00+01:00", "created": "2021-03-03T00:07:56+01:00", "restricted": false, "active": true, "prohibit_login": false, "location": "", "website": "", "description": "", "visibility": "public", "followers_count": 0, "following_count": 0, "starred_repos_count": 0, "username": "jenkins" } } ``` Try to upload a file as a generic package to elbandi/test: ``` $ curl --user jenkins:2bcb4b4293d6f624b49d22cdbf8f46b800c65cc5 \ --upload-file README.md \ https://git.elbandi.net/api/packages/elbandi/generic/test/1.0.0/file.bin reqPackageAccess $ ``` unsuccessful :( Try to upload a file as a generic package to an organisation package: ```shell $ curl --user jenkins:2bcb4b4293d6f624b49d22cdbf8f46b800c65cc5 \ --upload-file README.md \ https://git.elbandi.net/api/packages/kubernetes/generic/test/1.0.0/file.bin $ ``` it works.

GiteaMirror commented

@chrisliebaer commented on GitHub (May 20, 2024):

Sadly, this issue covers quite an important feature, but the discussion has been dissolved by unrelated topics of improper configuration.

As highlighted by others, at the very least, a note should be placed here: https://docs.gitea.com/usage/actions/comparison#missing-features I just spent 2 hours assuming that Gitea would support this feature, as it's very common and not listed.

Creating a PAT does not solve this issue. A PAT can not be scoped to a single repo, has to be created manually, and managed / copied / or stored (unless we want to end up with multiple PATs)

Gitea already associates packages with repos, so mirroring GitHubs should probably be supported without changes to Giteas design.

The basic flow should probably be something like this:

runner token gets access to write (some) packages of ${{ github.repository_owner }} namespace
packages uploaded with this token get added to ${{ github.repository_owner }} packages and associated with repo
if the package is already associated with a different repo (one for which we don't have an access token) the modification is rejected

This also means that if UserB pushes changes to a repo owned by UserA, the token will have access to the UserA package namespace.

Now I don't have any idea what your goals and concerns are, but PATs should be seen as a workaround, not as a solution, since they are clumsy, error-prone and give access to the namespace of the owner.

@chrisliebaer commented on GitHub (May 20, 2024): Sadly, this issue covers quite an important feature, but the discussion has been dissolved by unrelated topics of improper configuration. As highlighted by others, at the very least, a note should be placed here: https://docs.gitea.com/usage/actions/comparison#missing-features I just spent 2 hours assuming that Gitea would support this feature, as it's very common and not listed. Creating a PAT does not solve this issue. A PAT can not be scoped to a single repo, has to be created manually, and managed / copied / or stored (unless we want to end up with multiple PATs) Gitea already associates packages with repos, so mirroring GitHubs should probably be supported without changes to Giteas design. The basic flow should probably be something like this: 1. runner token gets access to write (some) packages of `${{ github.repository_owner }}` namespace 2. packages uploaded with this token get added to `${{ github.repository_owner }}` packages and associated with repo 3. if the package is already associated with a different repo (one for which we don't have an access token) the modification is rejected This also means that if UserB pushes changes to a repo owned by UserA, the token will have access to the UserA package namespace. Now I don't have any idea what your goals and concerns are, but PATs should be seen as a workaround, not as a solution, since they are clumsy, error-prone and give access to the namespace of the owner.

GiteaMirror commented

@philkunz commented on GitHub (May 24, 2024):

@lunny What would be the right way of getting this going?

@philkunz commented on GitHub (May 24, 2024): @lunny What would be the right way of getting this going?

GiteaMirror commented

@lunny commented on GitHub (May 25, 2024):

Create a PAT with permission of package and use that PAT to do login, push.

@lunny commented on GitHub (May 25, 2024): Create a PAT with permission of package and use that PAT to do login, push.

GiteaMirror commented

@alex3305 commented on GitHub (Jul 27, 2024):

As a temporary workaround I have defined an actions user which I gave sufficient rights on the repositories that I want to use actions with. Or in my case I've made this an admin user which cannot login through the web UI. The latter I disabled as a final step.

For this user I created a PAT ~~and set that up as a secret variable on the Actions > Secrets page on the user's profile as PACKAGES_TOKEN so I can use that variable within my Actions.~~ Appearently I still have to set that PAT on my own profile as well. Otherwise the secret cannot be found. I can than use a pretty similar approach to the intended one:

name: Docker Build and Push
run-name: ${{ gitea.actor }} is running Docker build and push

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Login to local Gitea registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.registry }}
          username: ${{ env.actions_user }}
          password: ${{ secrets.PACKAGES_TOKEN }}
      - name: Docker Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ env.registry }}/${{ gitea.repository }}:latest

Note that I also defined my registry and actions user in my runner's config.yaml:

runner:
  envs:
    registry: gitea.mydomain.tld
    actions_user: actions

This seems to work perfectly. Or at least for the time being 😄 .

Instead of using a dedicated user you could also opt to set your own username as the actions_user and add the PAT to your Actions > Secrets in your profile.

@alex3305 commented on GitHub (Jul 27, 2024): As a temporary workaround I have defined an `actions` user which I gave sufficient rights on the repositories that I want to use actions with. Or in my case I've made this an admin user which cannot login through the web UI. The latter I disabled as a final step. For this user I created a PAT ~and set that up as a secret variable on the Actions > Secrets page on the user's profile as `PACKAGES_TOKEN` so I can use that variable within my Actions.~ Appearently I still have to set that PAT on my own profile as well. Otherwise the secret cannot be found. I can than use a pretty similar approach to the intended one: ```yaml name: Docker Build and Push run-name: ${{ gitea.actor }} is running Docker build and push on: push: jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Login to local Gitea registry uses: docker/login-action@v3 with: registry: ${{ env.registry }} username: ${{ env.actions_user }} password: ${{ secrets.PACKAGES_TOKEN }} - name: Docker Build and push uses: docker/build-push-action@v6 with: context: . push: true tags: ${{ env.registry }}/${{ gitea.repository }}:latest ``` Note that I also defined my registry and actions user in my runner's `config.yaml`: ```yaml runner: envs: registry: gitea.mydomain.tld actions_user: actions ``` This seems to work perfectly. Or at least for the time being 😄 . Instead of using a dedicated user you could also opt to set your own username as the `actions_user` and add the PAT to your Actions > Secrets in your profile.

GiteaMirror commented

2025-11-02 09:09:00 -06:00

@jonas-switala commented on GitHub (Oct 3, 2024):

As a temporary workaround I have defined an actions user which I gave sufficient rights on the repositories that I want to use actions with. Or in my case I've made this an admin user which cannot login through the web UI. The latter I disabled as a final step.

I'm curious how you got that to work?

While creating a separate 'actions_user' with a PAT and write access to packages works for me to publish packages for my organization (by setting PACKAGES_TOKEN as a secret at the organization level), I have observed that it is not possible to disable login for that user after creating the PAT, since this does not only prohibit login to the web UI but also to the packages registry using the PAT.
In contrast to you I'm testing with the PyPi repo and my 'actions_user' doesn't have admin permissions but write acces to all repos in the organization. I don't think this should make a difference though.

@jonas-switala commented on GitHub (Oct 3, 2024): > As a temporary workaround I have defined an actions user which I gave sufficient rights on the repositories that I want to use actions with. Or in my case I've made this an admin user which cannot login through the web UI. The latter I disabled as a final step. I'm curious how you got that to work? While creating a separate 'actions_user' with a PAT and write access to packages works for me to publish packages for my organization (by setting PACKAGES_TOKEN as a secret at the organization level), I have observed that it is not possible to disable login for that user after creating the PAT, since this does not only prohibit login to the web UI but also to the packages registry using the PAT. In contrast to you I'm testing with the PyPi repo and my 'actions_user' doesn't have admin permissions but write acces to all repos in the organization. I don't think this should make a difference though.

GiteaMirror commented

@jbalonso commented on GitHub (Oct 7, 2024):

As highlighted by others, at the very least, a note should be placed here: https://docs.gitea.com/usage/actions/comparison#missing-features I just spent 2 hours assuming that Gitea would support this feature, as it's very common and not listed.

I have filed a PR here: https://gitea.com/gitea/docs/pulls/77.

@jbalonso commented on GitHub (Oct 7, 2024): > As highlighted by others, at the very least, a note should be placed here: https://docs.gitea.com/usage/actions/comparison#missing-features I just spent 2 hours assuming that Gitea would support this feature, as it's very common and not listed. I have filed a PR here: https://gitea.com/gitea/docs/pulls/77.

GiteaMirror commented

2025-11-02 09:09:00 -06:00

@minionflo commented on GitHub (Apr 13, 2025):

any updates on this?

@minionflo commented on GitHub (Apr 13, 2025): any updates on this?

GiteaMirror commented

2025-11-02 09:09:00 -06:00

@omnicortex commented on GitHub (Jun 18, 2025):

any progress?

@omnicortex commented on GitHub (Jun 18, 2025): any progress?

GiteaMirror commented

@lunny commented on GitHub (Jun 18, 2025):

Maybe it should be allowed to login and operate the repository related package. But it cannot pushing new package or visit the packages which is unrelated to the repository the actions running.

@lunny commented on GitHub (Jun 18, 2025): Maybe it should be allowed to login and operate the repository related package. But it cannot pushing new package or visit the packages which is unrelated to the repository the actions running.

GiteaMirror commented

@marvint24 commented on GitHub (Jun 18, 2025):

Maybe it should be allowed to login and operate the repository related package. But it cannot pushing new package or visit the packages which is unrelated to the repository the actions running.

I think it would be an improvement, but it would not be straight forward. Because if I understand you correctly you would always need to upload a package initially and link it before a pipeline could update it.

I am currently using a separate token for private repos and a separate user and token for organizations and this approach works quite well for me. Maybe a solution could be to automatically set a secret (e.g. RUNNER_TOKEN) that could be used in pipelines to access the packages.

@marvint24 commented on GitHub (Jun 18, 2025): > Maybe it should be allowed to login and operate the repository related package. But it cannot pushing new package or visit the packages which is unrelated to the repository the actions running. I think it would be an improvement, but it would not be straight forward. Because if I understand you correctly you would always need to upload a package initially and link it before a pipeline could update it. I am currently using a separate token for private repos and a separate user and token for organizations and this approach works quite well for me. Maybe a solution could be to automatically set a secret (e.g. RUNNER_TOKEN) that could be used in pipelines to access the packages.

GiteaMirror commented

@idchlife commented on GitHub (Aug 28, 2025):

So, would I be correct in saying that the GITEA token authentication currently does not work, and PAT should be used instead as a workaround?

@idchlife commented on GitHub (Aug 28, 2025): So, would I be correct in saying that the GITEA token authentication currently does not work, and PAT should be used instead as a workaround?

GiteaMirror commented