Can we have "Allow specified actors to bypass required status checks" settings?

[Colin-b]

Select Topic Area

Question

Body

As of right now, using GitHub Enterprise, I can put, under the required pull requests, the following settings:

• Allow specified actors to bypass required pull requests

This allows me to have some account that can push to a protected branch without using a pull request (for some automated flow, typically auto-versioning, but it could be anything else really).

The problem is that, if you put required status checks, the push will fail, as it's a direct push to the protected branch (so there is no status).
In order to keep consistency, I think the following setting should be introduced for status checks, the same way it already exists for pull requests:

• Allow specified actors to bypass required status checks

This will allow to put status checks as required, such as status that are pull requests specific (only triggered when a pull request is opened, synchronized or reopened). Because right now there is no way to mark those status as required while having someone bypassing pull requests.

Thanks again

[justinmchase]

I came here to ask this exact same question for the same reason; I am attempting to build automation around versioning.

I am using the release-drafter action, which will produce a Draft Release as users are merging their PR's and it formulates a new version based on the labels of the accumulated PR's. I have made a Github App which responds to release.draft events and will make a commit based on the label of the release. That way when the user publishes the release, the Tag that is created is for a commit which already has that version applied in code.

My code, as is very common across many different application languages and runtimes, requires the version to be located somewhere in the code (or multiple places). If I'm automating the process of incrementing versions I need a way to apply that version to the code in an automated way. Being unable to push into main branch without granting excessive admin permissions is very prohibitive.

That's my scenario but I think its safe to say that regardless of my workflow here there exists legitimate scenarios where automation should be able to push commits directly to protected branches without review. These commits should not require admin privileges though it seems reasonable to require that these users / apps / teams be granted that permission specifically.

If that above statement is true then I 2nd @Colin-b's comments and proposed solution; an "Allow specified actors to bypass required status checks" is a perfect solution.

[justinmchase]

Another way to phrase this is that it seems like if you cannot commit without the status checks then there is no point it allowing a user to bypass pull requests because there seems to be no way to actually run the checks against a commit without a pull request (since actions typically only trigger on pull_request events).

And after some experimentation, if your user who can bypass pull requests does create a Pull Request to trigger the status checks, then they still cannot merge the PR if you have other requirements (such as approval related requirements).

So it seems like the bypass pull requests feature does absolutely nothing if you cannot also bypass status checks.

[justinmchase]

I was able to actually bypass the other checks by using the --admin flag with the gh cli. The user isn't actually an admin but because they can commit without a PR it seems to work.

Therefore the workaround is to create a PR, listen for check_suite events and then once completed attempt to merge the pr with --admin flag.

[Colin-b]

There is a bunch of workaround yes, however, except for the one disabling the status checks pre-push and reactivating them after the push, none is "instant", meaning they all introduce a delay in actually doing the push in the target branch of the modified files.

In my use case I need it to be as fast as possible and relying on actions is not an option as you might be waiting for a runner.

[justinmchase]

Also doing it in an action is potentially problematic since, anyone can make a PR with adjustments to that action which could allow it to make commits you don't want to allow.

In my case I made a github app, which has to go through its own code review process and has a user tied to it which has to have the specific permissions.

But yes I agree still, that app still can't commit with these status checks in place without creating a whole PR and auto merging it after the statuses are run, which has a delay and can run into extra problems.

[justinmchase]

Would it make sense to just have the "Allow specified actors to bypass pull requests" to just also always be allowed to bypass status checks? It seems pointless to be able to bypass PR's without being able to also be able to bypass status checks.

[travi]

But my status checks are triggered by PR specifically, so how can I run that check against a commit without the corresponding pull_request event?

checks that are set as a result of a pull_request trigger would never be triggered without a PR, you are correct. my point is that not all projects have required checks that are the result of pull_request triggers. checks that result from push triggers, for example, can be satisfied without a PR.

[Colin-b]

For information, status checks are not workflow specific, so you can have the same status check from the one on your PR related triggers but triggered upon push (and doing nothing let's say, so that you have instant success upon job run).

However this, of course, introduce unnecessary complexity in your actions and still requires to wait for a runner. Also it would require the following flow: push to another non protected branch -> trigger all the required status checks with success -> merge this branch within your protected branch without a PR.

[justinmchase]

I see, I didn't realize you could trigger it off of a push specifically. Right now what I'm doing in my App when I need to commit to main, is to create a branch, push the changes there, then create a PR. That then triggers all push and pr events. After each check_suite complete event is sent to my app successfully I try to merge the branch, eventually it will work as all the required status_checks complete.

one example i have for this is with renovate.

@travi Can you elaborate? I'm not sure what that is.

So in your scenario where you are granting specific users the ability to push to a branch, but they must run status checks off of the "push" events and then merge to main without a PR, is it safe to say these are people and not automated processes? And if so why is it ok for them to do this? In my company this would violate our audibility requirements.

I could also envision a situation where you want to require the PR for audit trail purposes but you want to allow certain users to bypass the checks if they need to merge...

It does seem like there is a distinction between Human users and Automation users, which is probably hard to infer completely.

So considering that, a second option for adding users who can bypass status checks for the branch sounds like the best way to be flexible to any scenario, while being still pretty easy to understand. The one setting up the branch protections would know that the user they are specifically granting bypasses too is human or a robot and their intent best.

[travi]

It seems pointless to be able to bypass PR's without being able to also be able to bypass status checks.

@justinmchase the information that i've added to this thread is in response to this suggestion. i'm just trying to highlight that there are valid use cases where the lists would need to be different, so it isnt reasonable to expect defining a single list to handle all of these cases.

i'm not suggesting that this applies to your use case and i dont know enough about your context to suggest what would work for you. i dont think solving for your use case is useful here.

[justinmchase]

Yeah thats fair, I think I'm agreeing with you, just walking through the logic.

[cloph]

same: #18145

[Colin-b]

Indeed, however the category might be misleading. Do GH developers even check this and can we hope for an answer? I see that this thread is already half a year old.

[Macmee]

Hey, I think this is broken. When trying to specify a team for "Allow specified actors to bypass required pull requests" the autocomplete selector will now surface teams, only users.

[justinmchase]

I'm now realizing that if you have a CODEOWNER specified, then you can't even merge the PR automatically without a PR review regardless of any settings.

[bahag-gugelm]

Still an issue. Signing under all above.

[gmocquet]

Same issue here

[jummethum]

I also have same isse

[bahag-gugelm]

A way to circumvent the branch protection rules and to be able to commit and push the version bump and the changelog from an action back to the code, could be using an SSH key pair added to the repo, the public part as a deploy key (with r/w permissions) and both private/public ones as the repository secrets. In order to work correctly, one has also perform checkout using the supplied key. For publishing to the GH release, the default runner token (GITHUB_TOKEN) is sufficient. Also, don't forget to pass those secrets to the job with a parameter secrets: inherit while calling it from the parent workflow.

release.yaml example

 
on:
  workflow_call:
 
env:
  GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  SSH_PUBLIC_KEY: ${{ secrets.SSH_PUBLIC_KEY }}
  SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
  GIT_COMMITTER_NAME: semantic-release
  GIT_COMMITTER_EMAIL: github-actions@github.com
 
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v4
        with:
          python-version: 3.9
      - name: Git & SSH auth setup
        run: |
          # See https://github.com/actions/runner-images/issues/6775#issuecomment-1409268124
          # and https://github.com/actions/runner-images/issues/6775#issuecomment-1410270956
          sudo git config --system --add safe.directory "*"
          if [[  -n $SSH_PUBLIC_KEY && -n $SSH_PRIVATE_KEY ]]; then
              echo "SSH Key pair found, configuring signing..."
              mkdir ~/.ssh
              echo -e "$SSH_PRIVATE_KEY" >> ~/.ssh/signing_key
              cat ~/.ssh/signing_key
              echo -e "$SSH_PUBLIC_KEY" >> ~/.ssh/signing_key.pub
              cat ~/.ssh/signing_key.pub
              chmod 600 ~/.ssh/signing_key && chmod 600 ~/.ssh/signing_key.pub
              eval "$(ssh-agent)"
              ssh-add ~/.ssh/signing_key
              git config --global gpg.format ssh
              git config --global user.signingKey ~/.ssh/signing_key
              git config --global commit.gpgsign true
              git config --global user.email $GIT_COMMITTER_EMAIL
              git config --global user.name $GIT_COMMITTER_NAME
              touch ~/.ssh/allowed_signers
              echo "$GIT_COMMITTER_EMAIL $SSH_PUBLIC_KEY" > ~/.ssh/allowed_signers
              git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers
          fi
      - name: Checkout code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ssh-key: ${{ env.SSH_PRIVATE_KEY }}
      - name: Semantic Release
        run: |
          pip install python-semantic-release
          semantic-release publish -D commit_author="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"

[justinmchase]

Can this work for apps? What if you're installed on a ton of repos?

Can any workflow, in any branch now make any commit now? Or does this just commit into an unprotected branch?

[bahag-gugelm]

This is just a way to commit from an action to any protected branch that I finally came up with. Sure, it's an individual repo solution, and it doesn't require any github app to impersonate it as an actor to be added to the branch protection bypass whitelist.

[wheelerlaw]

This is what GitHub needs to implement:

[torressam333]

I added a CI User as an admin to my repo and I can't find their individual user in my ruleset bypass list.

[torressam333]

@patrick-knight

[patrick-knight]

Creating a team or role for that actor would be the way to handle that, as we don't list named users directly in the bypass lists.

[torressam333]

Makes sense. If I layer a ruleset to allow the CI user to merge into my dev branch, will that work in conjunction with my existing dev branch protection rules? Which one of the two takes precedence?

[patrick-knight]

They layering works to ensure all protections from rules and branch protections must be true. If an actor has conflicting bypasses across rules and branch protections, that actor would not bypass as both have to be true to allow the bypass.

Here are the details in the docs about that behavior

[na-jakobs]

Much needed feature 🙏

[tuomaskujala]

+1 for this!

[svanherk]

I was very optimistic this was solved by the new Rulesets functionality, but it doesn't appear to work for our use case (using a GitHub app token).

[justinmchase]

It seems like it is intended to be the solution for this and there are simply some errors. Keep checking in with it as it progresses to be out-of-beta status.

[patrick-knight]

Apps should be working now for all bypass scenarios.

[ravi-vunet]

+1 for this

[patrick-knight]

Y'all should check out Repository rules for this use case.

Rulesets support layering, meaning you can set a craft a set of rulesets that have bypass targets on apps, roles or teams. You can configure rules in such a way you can enforce status checks for all, but allow the bots or teams to merge bypass those requirements.

In this case you’d create two rulesets in your repo.

Required for some

• Bypass list:
• Target branches: default branch
• Branch Protections:
• Enable: “Require status checks to pass before merging” and “Require branches to be up to date before merging”

Required for all

• Bypass list: empty
• Target branches: default branch
• Branch Protections:
• Enable: “Restrict Deletions”
• Enable: “Block force pushes”

Theres a discussion for rules over here

[justinmchase]

So are the rules not a logical AND?

[wheelerlaw]

They are more similar to "bitwise" OR.

[MikeDabrowski-EQM]

Close but we are unable to add github-actions user to bypass list

[jdbruijn]

Just tried it yesterday as well, after the June 27, 2023 updates on the rules. Works great now with empty branch protection rule on main to prevent deletion and force pushes and then rules on main to require status checks before merging, allowing app to bypass 😄

[jummethum]

I also tried this approach and added the 2 rules for my master (default) branch. But I cannot get the bypass users to work. I added Admins / Maintainers / Github App User. All 3 didnt seem to work and I always get the Error Message: Push Rejected - 3 out of 3 required Checks are expected. Anyone else have this issue?

[jayshah123]

Quite a useful feature for version bump and other use cases.

[nnellanspdl]

Really need something like this. It's blocking my automation attempts.

[mkienenb]

switching from "branch" rule protection to "ruleset" protections let my Github App bot bypass required status checks, so that's definitely the way to go.

[torressam333]

How?

[patrick-knight]

Here's the docs for rulesets and a screenshot of what the bypass list offers with a few examples.

[alper]

What does this setting even do?

"Allow specified actors to bypass required pull requests"

The brach protection rules are a total mess and it's nearly impossible to figure out what any one setting there does.

I need certain people to be able to merge PRs without waiting for checks or reviews. Not sure if this fits the bill there.

[ViliusS]

I agree, protection rules are complex to understand, but they are flexible and very powerful.

"Allow specified actors to bypass required pull requests" doesn't exist anymore in protection rules. What you must do instead is configure Bypass List for protection rules which you want your users to be able to skip. Bypass List can be applied in every context (for example direct commit rule to the branch), or in PR only context (for example review requirement rule).

So to answer your question directly. You should split your rules into the ones you want certain people to skip and the ones applied to everybody. Then add those certain people to checks/review rule under Bypass List with "For pull request only". For example:

1. Rule A for master branch - Block Force Pushes [x], Restrict Deletion [x]. Bypass List is empty.
2. Rule B for master branch - Require PR before mergin [x, at least 1 approval], Require Status Checks to Pass [x], Bypass List [YourCertainGroup - For PR Only].

These two rules will deny direct commits, force pushes and deletion operations on master branch and will require everybody to do PR, but CertainGroup will be allowed to skip approval and status checks on those PRs.

Personally I suggest that every rule implements one organizational policy. Policy examples:

1. Files larger than 2 MB require LFS.
2. Tags are never created manually.
3. Any modification of tags (force pushes, deletion, etc) are not allowed.
4. Force pushes and deletion of main development branches are prohibited.
5. Only CI bots can can merge into master.
6. Developers must always merge into develop.
   etc.

This way you will have a) structure, b) can decide who can skip policies, and who don't.

[alper]

This means we've been forcibly moved to Rulesets (which we now have to configure) without notification?

[ViliusS]

I don't understand what you mean. You can use either Rulesets, or Branch Protection, or both.

[wheelerlaw]

Branch protection settings have always lacked the ability to allowlist certain users from being required to pass status checks (unless you have them configured as repo admins and made sure that the branch protection settings are not being enforced for repo admins). But it does look like GitHub has removed the ability to allowlist certain users from being required to open a PR.

In either case, the only way to let a user bypass status checks is to use rulesets (this has always been the case).

[GarlonJG]

Has anyone figured this out fully yet? I'm running into a similar situation when attempting versioning through automation. I created a Githb App for our org. Gave it all the permissions I could find that I think it needs. Added it to my Bypass list in a ruleset where I've set a status check. In my workflow where I make a commit to update a versioning file, that's made after the PR is merged, the push to add the commit fails because it's seen as being pushed to the protected branch without the required status checks. When I turn off the status check, I can confirm the commit gets added by the app I created that I added to the bypass list.

Am I thinking about bypass actors in the wrong way when it comes to status checks? Do I need to create a temp branch first that can have the status check ran on it, then merge that into the protected branch during the flow? If so, what's the purpose of the bypass list then, if any, in that scenario? I was under the assumption that bypass actors can bypass any part of the ruleset their setup on.

These are the permissions I have for the app. Maybe a bit too much, but I figured I could take some back once it works:
Read access to actions variables, custom organization roles, custom repository roles, members, metadata, organization actions variables, organization events, and secrets

Read and write access to actions, administration, checks, code, commit statuses, deployments, issues, merge queues, organization self hosted runners, pull requests, and workflows

[GarlonJG]

Thanks @justinmchase. I am using rulesets instead of branch protections. Are you pushing commits directly to a protected branch, or to a branch first, then merging that branch into your protected branch?

And yep @ViliusS, when I turned off the status check, I saw that the commit was from the app I created. I also separated out my rulesets, and made the status check a ruleset by itself. If status checks work only on PRs, then I wonder if I'm doing something incorrect in my workflow then, or need to change my thinking on it? Here's some readout of a recent log a few minutes ago. And again, this comes right after the commit is made, while on the protected branch, and I'm pushing that commit to the protected branch. If status checks only work on PRs, then why is it running at this point in my workflow?

Caller workflow:

name: "PR Controller"
on:
  pull_request:
    types: [opened, labeled, unlabeled, edited, synchronize, closed]

job that runs after PR is closed:

  tag-release:
    runs-on: ubuntu-latest
    needs:
      - validate-labels
    if: github.event.pull_request.merged == true

Error log:

remote: error: GH013: Repository rule violations found for refs/heads/protected-branch.        
remote: Review all repository rules at https://github.com/owner/repo/rules?ref=refs%2Fheads%2Fprotected-branch        
remote: 
remote: - Required status check "validate-pr / validate-labels" is expected.        
remote: 
To https://github.com/owner/repo
 ! [remote rejected]   HEAD -> protected-branch (push declined due to repository rule violations)
error: failed to push some refs to 'https://github.com/owner/repo'

[justinmchase]

No I'm pushing straight to the main branch.

The rule requiring a pull request for the default branch can be bypassed.

Look in the sample I pasted above for this nugget:

gh auth setup-git

The action above it to get a gh token from the app cert will let you auth as the application. If I had to guess what your error is based on that info I'd say you're probably authing with the default workflow credentials instead of the users creds.

How are you authing git before pushing?

[GarlonJG]

Ok, and I'll check out the suggestion of gh auth setup-git. In terms of authing, @ViliusS got me onto another thought thread to verify the identity, and I realized I had the user.name and user.email incorrect for Github apps. Didn't know there was a standard format. I also realized I had to put the remote set-url line higher so that the commit would be seen as coming from the app. And sure enough I then saw a difference in the commit author when I had the status check turned off and pushed commits through without rulesets. Still didn't bypass the status check issue.

For a work-around, I ended up creating a temp branch, posting a status check on that, and then merging it into my protected branch. It works because I'm basically adding a successful status check (ie. too hacky). However, once I turned on the ruleset that a PR is needed with at least 1 approval, then I hit another road block again with now needing a PR before merging into the protected branch...

Regardless, here's my original workflow minus the temp branch work-around. It's the workflow making a commit and pushing straight to the protected branch. Hoping anyone can spot anything. Definitely, no worries if not. I've thrown it at ChatGPT from multiple angles and it still couldn't see what the issue is/was.

Real repo names/branches have not been used.

name: "PR Controller"
on:
  pull_request:
    types: [opened, labeled, unlabeled, edited, synchronize, closed]

jobs:
  check-exemption:
    uses: owner/centralized-repo/.github/workflows/pr-exemption-status.yml@master

  validate-pr:
    needs: check-exemption
    uses: owner/centralized-repo/.github/workflows/validate-tag-pr.yml@master
    with:
      is_exempt: ${{ needs.check-exemption.outputs.is_exempt }}
    secrets:
      AUTO_CI_CD_APP_ID: ${{ secrets.AUTO_CI_CD_APP_ID }}
      AUTO_CI_CD_PRIVATE_KEY: ${{ secrets.AUTO_CI_CD_PRIVATE_KEY }}
      AUTO_CI_CD_INSTALLATION_ID: ${{ secrets.AUTO_CI_CD_INSTALLATION_ID }}

  clickup-checks:
    needs: check-exemption
    if: github.event.action == 'opened' || github.event.action == 'edited' || github.event.action == 'synchronize'
    uses: owner/centralized-repo/.github/workflows/ensure-clickup-id.yml@master
    with:
      is_exempt: ${{ needs.check-exemption.outputs.is_exempt }}

name: "Validate PR Labels & Tag on Merge"
on:
  workflow_call:
    inputs:
      is_exempt:
        required: true
        type: string
    secrets:
      AUTO_CI_CD_APP_ID:
        required: true
      AUTO_CI_CD_PRIVATE_KEY:
        required: true
      AUTO_CI_CD_INSTALLATION_ID:
        required: true

jobs:
  validate-labels:
    runs-on: ubuntu-latest
    outputs:
      labels: ${{ steps.get-labels.outputs.labels }}
    steps:
      - name: Check PR Labels
        id: get-labels
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          LABELS=$(curl -s -H "Authorization: token $GITHUB_TOKEN" \
                  -H "Accept: application/vnd.github.v3+json" \
                  "https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/labels" | jq -r '.[].name' | tr '\n' ',')

          LABELS=$(echo "$LABELS" | sed 's/,$//')

          if [ -z "$LABELS" ]; then
            echo "❌ No labels found! This PR cannot be merged until labels are added."
            exit 1
          else
            echo "✅ Labels found: $LABELS"
            echo "labels=$LABELS" >> "$GITHUB_OUTPUT"
          fi
      
  tag-release:
    runs-on: ubuntu-latest
    needs:
      - validate-labels
    if: github.event.pull_request.merged == true
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.base.ref }}
      
      - name: Fetch PR Number from Event Context
        id: get-pr
        run: |
          echo "PR_NUMBER=${{ github.event.pull_request.number }}" >> $GITHUB_ENV
      
      - name: Extract Task ID from PR Body
        if: ${{ inputs.is_exempt == 'false' }}
        id: extract_task_id
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          PR_BODY=$(jq -r '.pull_request.body' "$GITHUB_EVENT_PATH")
          TASK_ID=$(echo "$PR_BODY" | sed -n 's/.*Task ID:[[:space:]]*\([A-Za-z0-9_-]\+\).*/\1/p')
          
          if [[ -z "$TASK_ID" ]]; then
            echo "❌ No Task ID found in PR body! Skipping update."
            exit 1
          fi
          
          echo "TASK_ID=$TASK_ID" >> $GITHUB_ENV
          echo "✅ Task ID extracted: $TASK_ID"

      - name: Authenticate using GitHub App
        id: app-auth
        env:
          APP_ID: ${{ secrets.AUTO_CI_CD_APP_ID }}
          PRIVATE_KEY: ${{ secrets.AUTO_CI_CD_PRIVATE_KEY }}
          INSTALLATION_ID: ${{ secrets.AUTO_CI_CD_INSTALLATION_ID }}
        run: |
          echo "Creating JWT for GitHub App authentication..."

          # Save the private key to a file
          printf "%s" "$PRIVATE_KEY" > private-key.pem

          # Generate JWT
          NOW=$(date +%s)
          EXP=$((NOW + 540)) # 9 minutes from now
          HEADER=$(echo -n '{"alg":"RS256","typ":"JWT"}' | openssl base64 -A | tr '+/' '-_' | tr -d '=')
          PAYLOAD=$(echo -n "{\"iat\":$NOW,\"exp\":$EXP,\"iss\":$APP_ID}" | openssl base64 -A | tr '+/' '-_' | tr -d '=')
          SIGNATURE=$(echo -n "$HEADER.$PAYLOAD" | openssl dgst -sha256 -sign private-key.pem | openssl base64 -A | tr '+/' '-_' | tr -d '=')
          
          JWT="$HEADER.$PAYLOAD.$SIGNATURE"

          echo "Fetching installation access token..."
          ACCESS_TOKEN=$(curl -s -X POST \
            -H "Authorization: Bearer $JWT" \
            -H "Accept: application/vnd.github+json" \
            https://api.github.com/app/installations/$INSTALLATION_ID/access_tokens | jq -r '.token')

          if [[ "$ACCESS_TOKEN" == "null" || -z "$ACCESS_TOKEN" ]]; then
            echo "❌ Failed to get GitHub App access token."
            exit 1
          fi

          echo "See what repos the token is valid for..."
          curl -H "Authorization: token $ACCESS_TOKEN" \
            -H "Accept: application/vnd.github+json" \
            https://api.github.com/installation/repositories

          echo "✅ GitHub App authenticated."
          echo "INSTALLATION_TOKEN=$ACCESS_TOKEN" >> $GITHUB_ENV

      - name: Configure Git identity
        run: |

          echo "Verifying token is being used..."
          curl -s -H "Authorization: token $INSTALLATION_TOKEN" https://api.github.com/user
          git config user.name "auto-ci-cd[bot]"
          git config user.email "auto-ci-cd[bot]@users.noreply.github.com"

          git remote set-url origin https://x-access-token:$INSTALLATION_TOKEN@github.com/${{ github.repository }}.git

      - name: Fetch latest tags
        run: git fetch --tags
        
      - name: Generate tags from labels
        id: generate_tags
        env:
          LABELS: ${{ needs.validate-labels.outputs.labels }}
        run: |
          TAGS=()
          IFS=',' read -r -a LABEL_ARRAY <<< "$LABELS" # Split comma-separated labels into an array
          
          EXEMPT_LABEL="No ClickUp Task Needed"
          SKIP_QGATES_LABEL="Skip Quality Gates"
          for label in "${LABEL_ARRAY[@]}"; do
            #skip these labels if found. We don't want to create tags for these labels.
            if [[ "$label" == "$EXEMPT_LABEL" || "$label" == "$SKIP_QGATES_LABEL" ]]; then
              if [[ "$label" == "$SKIP_QGATES_LABEL" ]]; then
                echo "RUN_QGATES=false" >> $GITHUB_ENV
              fi
              continue
            fi
            
            LATEST_TAG=$(git tag --list "$label-v*" | sort -V | tail -n 1 || true)
            echo "LATEST_TAG for $label: $LATEST_TAG"
            
            if [[ -z "$LATEST_TAG" ]]; then
              NEW_TAG="${label}-v1"
            else
              VERSION=$(echo "$LATEST_TAG" | sed -n 's/.*-v\([0-9]\+\)/\1/p')
              NEW_TAG="${label}-v$((VERSION + 1))"
            fi

            TAGS+=("$NEW_TAG")
            echo "Generated tag: $NEW_TAG"
          done

          echo "TAGS=${TAGS[*]}" >> $GITHUB_ENV

      - name: Create tags and update release-mappings.yml
        run: |
          echo "Updating release-mappings.yml and creating tags..."

          YAML_FILE="release-mappings.yml"
          TEMP_FILE="release-mappings.tmp.yml"

          if [[ ! -f "$YAML_FILE" ]]; then
            echo "tags: []" > "$YAML_FILE"
          fi

          for tag in $TAGS; do
            if git rev-parse "$tag" >/dev/null 2>&1; then
              echo "⚠️ Tag '$tag' already exists. Skipping..."
              continue
            fi

            if [[ -z "$TASK_ID" ]]; then
              TASK_ID="none"
            fi

            if [[ -z "$RUN_QGATES" ]]; then
              RUN_QGATES="true"
            fi

            yq eval '.tags += [{"git_tag": "'$tag'", "clickup_id": "'$TASK_ID'", "run_quality_gates": "'$RUN_QGATES'"}]' "$YAML_FILE" > "$TEMP_FILE"
            mv "$TEMP_FILE" "$YAML_FILE"
          done

          cat "$YAML_FILE"

          git add release-mappings.yml
          git commit -m "Update release-mappings.yml with new git tags"

          git push origin HEAD:${{ github.event.pull_request.base.ref }} #Needs to happen first, or else concourse won't see updated variables file
          
          for tag in $TAGS; do
            git tag "$tag" -m "Tagging release: $tag"
          done

          git push origin --tags #Needs to happen last

[GarlonJG]

Just wanted to post that I figured it out! For anyone who comes behind and has a similar problem, here's what I noticed:

@ViliusS had me recheck that I was making a commit as the app, and I realized that my user.name and user.email was not correct. For GitHub Apps, you must use "...[bot]" in user.name and "...[bot].users.noreply.github.com" for user.email.

Secondly, @justinmchase informed me about gh auth setup-git. Now even though I'm using it now, (thanks @justinmchase!), the issue was the order of my steps. My job started out with me checking out my repo as Github Actions. So simple, but obviously extremely easy to overlook. I had to change the order of the steps, so that ever step afterwards was coming from the app.

wrong order:

  tag-release:
    runs-on: ubuntu-latest
    needs:
      - fetch-pr
    env:
      LABELS: ${{ needs.fetch-pr.outputs.labels }}
      TASK_ID: ${{ needs.fetch-pr.outputs.task_id }}
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Authenticate using GitHub App
        id: app-auth
        env:
          APP_ID: ${{ secrets.HES_CI_CD_APP_ID }}
          PRIVATE_KEY: ${{ secrets.HES_CI_CD_PRIVATE_KEY }}
          INSTALLATION_ID: ${{ secrets.HES_CI_CD_INSTALLATION_ID }}
        run: |
          echo "Creating JWT for GitHub App authentication..."
          ...

You need to authenticate first, then check out the repo and whatever else you need to do.

Successful logs:

remote: Bypassed rule violations for refs/heads/protected-branch:        
remote: 
remote: - Required status check "validate-pr / validate-labels" is expected.        
remote: 

And this is yet another reason, that even after 5 days of conversation and 1mil iterations of code with AI, us devs can't be replaced yet! 😂

[ViliusS]

Another thing that no GenAI will tell you, just use GitHub App Action to simplify your custom code.