Skip to content

Pushing via gitea workflows is not possible when branch protection is enabled, even if the branch protection rules would allow the push #38278

Description

@simongregorebner

Gitea Version

1.27.0+dev-210-g67f86bc3fe built with go1.26.3-X:jsonv2 : bindata, timetzdata,

What happened?

Whenever branch protection is enabled with a branch pattern that matches the branch being pushed, git push by the runner user into the repo is not possible, although the following rules would allow the push.

While doing the same thing on the commandline with my personal access token it works fine. I can push changes to the branch without any issues (except of course if i push into .gitea/* which is restricted).

Example workflow:

name: Test

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  autodeploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout caller repository
        uses: actions/checkout@v4

      - name: Create random file to commit afterwards
        shell: bash
        run: |
          touch $(date +%s).txt
      
      - name: Commit and push changes
        shell: bash
        run: |
          git config user.name "gitea-actions-bot"
          git config user.email "gitea-actions-bot@users.noreply.gitea.psi.ch"
          git add -A
          git commit -m "Update"
          git push origin

Example branch protection rules:
Image

Actions Token Permissions:
Image

Disabling branch protection and/or changing the branch pattern so that it doesn't match the branch being pushed allows the push to succeed.

We think the cause of the problems might be in the way branch protection rules are evaluated in the gitea source code. It looks like that still some user checks are done for the user, and as the runner user is not a real user checks and the whole evaluation fails.

How we interpret the source code we expect the problem to be in the following checks/functions and the way the checks are chained together:

func preReceiveBranch(ctx *preReceiveContext, oldCommitID, newCommitID string, refFullName git.RefName) {

(we didn't verify this assumption, we only briefly looked at the source code and the way the checks are chained together)

We also found this issue, but this is not the same problem, as the branch protection rules are clearly defined to only apply for certain paths of the repo, whitelisting etc. should not be necessary in this case.
#5163 (comment)

How are you running Gitea?

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions