Labels are not being correctly applied to PR using `GITHUB_TOKEN` #1074

syaghoubi00 · 2025-01-14T22:06:07Z

version:

Run googleapis/release-please-action@v4
Running release-please version: 16.12.0

It seems like release-please thinks it is adding the label successfully, even though no labels are added.

I ran the action with debug log enabled, and at the end of the pr output, "labels":[] is empty, but reporting Successfully added labels autorelease: pending.

Snippet of debug log:

✔ Successfully opened pull request: 2.
✔ Successfully added labels autorelease: pending to issue: 2
##[debug]Node Action run completed with exit code 0
##[debug]Set output releases_created = false
##[debug]Set output paths_released = []
##[debug]Set output prs_created = true
##[debug]Set output pr = {"headBranchName":"release-please--branches--main","baseBranchName":"main","number":2,"title":"chore(main): release 1.0.0","body":":robot: I have created a release *beep* *boop*\n---\n\n\n## 1.0.0 (2025-01-14)\n\n\n### Bug Fixes\n\n* test release ([13765cf](https://github.com/syaghoubi00/actions-testing/commit/13765cf982996c53e86ac13e83115f7843c335ee))\n\n---\nThis PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).","files":[],"labels":[]}

Possibly related: #1072 - however, adding the repository-projects: read permission did not fix the issue.

config:

on:
  push:
    branches:
      - main

permissions:
  contents: write
  pull-requests: write
  repository-projects: read
name: release-please

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: simple

It might be worth noting that this isn't a problem when using a PAT instead of the GH token.

The text was updated successfully, but these errors were encountered:

syaghoubi00 · 2025-01-14T23:35:08Z

#1028 - May also be related, as merging the unlabeled PR causes another PR to be opened instead of creating the release.

#1006 seems to confirm the that the labeling issue is causing a loop.

✔ Successfully found branch HEAD sha "13765cf982996c53e86ac13e83115f7843c335ee".
✔ Successfully created branch at https://api.github.com/repos/syaghoubi00/actions-testing/git/refs/heads/release-please--branches--main
✔ Got the latest commit tree
✔ Successfully created a tree with the desired changes with SHA d37132e2365a94caa53e06b7ba7463ad1044faaa
✔ Successfully created commit. See commit at https://api.github.com/repos/syaghoubi00/actions-testing/git/commits/321629a5187e032566f82ae44fcb851229f2620b
✔ Updating reference heads/release-please--branches--main to 321629a5187e032566f82ae44fcb851229f2620b
✔ Successfully updated reference release-please--branches--main to 321629a5187e032566f82ae44fcb851229f2620b
✔ Successfully opened pull request available at url: https://api.github.com/repos/syaghoubi00/actions-testing/pulls/2.
✔ Successfully opened pull request: 2.
✔ Successfully added labels autorelease: pending to issue: 2

HEAD (19abe7a) - squash merge commit of PR-2

 ✔ Successfully found branch HEAD sha "19abe7a51489de29f6ab0ba7bc1288040b3ece28".
✔ Skipping branch creation step...
✔ Got the latest commit tree
✔ Successfully created a tree with the desired changes with SHA 32bc9007e09c658767393e7f7e9c00ccb0a432c0
✔ Successfully created commit. See commit at https://api.github.com/repos/syaghoubi00/actions-testing/git/commits/10256b31d6f177bfa9c74f6ecc34642c329f1d8c
✔ Updating reference heads/release-please--branches--main to 10256b31d6f177bfa9c74f6ecc34642c329f1d8c
✔ Successfully updated reference release-please--branches--main to 10256b31d6f177bfa9c74f6ecc34642c329f1d8c
✔ Successfully opened pull request available at url: https://api.github.com/repos/syaghoubi00/actions-testing/pulls/3.
✔ Successfully opened pull request: 3.
✔ Successfully added labels autorelease: pending to issue: 3

Aaron-Ritter · 2025-01-15T20:11:13Z

fyi i updated #1072 it does only work once you've run it once with a PAT and then switch back to the normal github_token. It is not creating the labels.

when you manually create two labels autorelease: pending and autorelease: tagged it starts working

axieum · 2025-01-16T13:38:46Z

when you manually create two labels autorelease: pending and autorelease: tagged it starts working

This would explain why my older repositories continued to work, came here to note that label creation is blocked by default.

Aaron-Ritter · 2025-01-16T13:40:48Z

@axieum do you know a way to allow the label creation? none of the github_token permissions work, so is it a configuration or does it mean we have to create the labels manually?

axieum · 2025-01-16T14:42:21Z

I'm not entirely sure, I just created the two labels and called it a day. Once it's setup and running, it's fine - just a minor inconvenience. 😅

looztra · 2025-01-16T16:11:37Z

you can do that with an action like https://github.com/crazy-max/ghaction-github-labeler for instance

looztra · 2025-01-16T16:32:33Z

someone tried with the permission issues: write?

Aaron-Ritter · 2025-01-16T16:33:16Z

I guess it's a valid workaround by side manually creating then, but release-please explicitly states that they create these labels so it still is a bug, would you agree?

Aaron-Ritter · 2025-01-16T16:35:14Z

someone tried with the permission issues: write?

Yes I even tried all different write permission, adding each one by one.

ipauldev · 2025-01-16T16:54:43Z

I was able to correct this issue by creating labels first, using the cli. Once the labels exist, there appear to be no issues.

When I tried to add a label using gh cli, to the PR, it said the label did not exist. It seems that labels are not auto-creating when adding them to a PR.

I added this to all my newly created repos using release-please, to resolve the issue:

gh label create "autorelease: pending"
gh label create "autorelease: tagged"
gh label create "autorelease: snapshot"
gh label create "autorelease: published"

looztra · 2025-01-16T17:00:02Z

alternative: I used https://github.com/crazy-max/ghaction-github-labeler to make sure the labels exists

looztra · 2025-01-16T17:00:33Z

someone tried with the permission issues: write?

Yes I even tried all different write permission, adding each one by one.

ok, so the prob is not the action cannot create the labels, it's that it does not try to create it if it doesn't exist (it seems)

mancinifprom · 2025-01-17T10:42:02Z

Different scenario here , using token from github app with read-write access to pull-requests (hence access to labels).
in action logs i see:

✔ Successfully opened pull request: 9.
✔ Successfully added labels autorelease: pending to issue: 9

still the PR has no labels attached.

the action has always created this labels, i don't recall to ever have created this labels manually

henrikig · 2025-01-17T12:24:21Z

Using ghaction-github-labeler solved this issue for me as well. Adding sample configuration here for anyone stumbling across this:

# .github/labels.yml
- name: "autorelease: pending"
  color: "d73a4a"
  description: "Pending release"
- name: "autorelease: tagged"
  color: "d4c5f9"
  description: "Ready for release"
- name: "autorelease: snapshot"
  color: "d4c5f9"
  description: "Ready for release"
- name: "autorelease: published"
  color: "0e8a16"
  description: "Released"

# .github/workflows/labels.yml
name: github-labels

on:
  push:
    branches:
      - 'main'
    paths:
      - '.github/labels.yml'
      - '.github/workflows/labels.yml'
  pull_request:
    paths:
      - '.github/labels.yml'
      - '.github/workflows/labels.yml'

jobs:
  labeler:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run Labeler
        uses: crazy-max/ghaction-github-labeler@v5
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          skip-delete: true
          dry-run: ${{ github.event_name == 'pull_request' }}

penalbaxplor · 2025-01-23T15:28:21Z

I have the same problem. I had to manually tag (autorelease: pending) and finally the loop stopped. But this was not necessary before

UnP1u9 · 2025-01-24T13:41:58Z

Same here,

  - name: Add labels to the repository if not present
    env:
      GH_TOKEN: ${{ github.token }}
    run: |
      gh label create "autorelease: pending" || true
      gh label create "autorelease: tagged" || true
      gh label create "autorelease: snapshot" || true
      gh label create "autorelease: published" || true

I am using this in the pipeline for a temp fix.

bodgit · 2025-01-27T16:54:12Z

I think this is a wider GitHub issue, some behaviour which was previously relied on has changed.

We also use Renovate which should also be creating and adding labels to PRs but I notice it's not creating them either, without any sort of error. Like release-please, this used to work.

FYI I'm using an App with pull-requests: write permission.

Edit: I have an enterprise account so I've raised a support ticket to find out more.

Aaron-Ritter · 2025-01-27T20:15:08Z

I think this is a wider GitHub issue, some behaviour which was previously relied on has changed.

We also use Renovate which should also be creating and adding labels to PRs but I notice it's not creating them either, without any sort of error. Like release-please, this used to work.

FYI I'm using an App with pull-requests: write permission.

Edit: I have an enterprise account so I've raised a support ticket to find out more.

works for me with the following permissions

permissions:
    contents: write
    pull-requests: write
    repository-projects: read
    # only required for workflows in private repositories
    actions: read

clarification

Creating the labels manually works with these permissions. but i have to create the labels

syaghoubi00 · 2025-01-27T23:31:06Z

@Aaron-Ritter I just tried the action with those permissions in a private and public repo and it is still not creating the labels and is doing the PR loop.

I don't think it's a permission issue, as I just tried permissions: write-all too, which, per GitHub Token Permissions should give read and write permissions to everything. But it is still not creating the labels.

Aaron-Ritter · 2025-01-27T23:36:14Z

@syaghoubi00

thats the part i tried successfully, i defined it as a job required before the release-please job:

https://github.com/sonderformat-llc/run-quickstart-e2e-test/blob/66fa6a481d5f40fd42ee7bb46c3d44a7296fccb8/.github/workflows/release.yaml#L18-L35

FYI i edited my earlier comment, i meant that i can create the labels manually with the gh label create command. sorry for the confusion

dy0gu · 2025-01-27T23:49:31Z

Seems to be GitHub that broke label creation permissions on the GITHUB_TOKEN, not really a release-please issue, see here for other people experiencing the same with other actions: https://github.com/orgs/community/discussions/149877#discussioncomment-11952379

Aaron-Ritter · 2025-01-28T08:40:13Z

up-voted

bodgit · 2025-01-28T11:01:27Z

I think what is broken is what I'd term "autovivification" of labels.

Using the following:

curl -v --location --request POST 'https://api.github.com/repos/{owner}/{repo}/issues/{number}/labels' \
  --header 'Accept: application/vnd.github.v3+json' \
  --header 'Authorization: Bearer ${{ secrets.github_token }}' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "labels": ["nonexistent", "bug"]
  }'

The label bug exists, the label nonexistent does not. Only bug gets added to the issue/PR. An HTTP 200 response code is always returned.

I'm assuming previously any label that didn't exist when adding it to an issue/PR would be automatically created/vivified.

I've tried the built in token and an app token, both only with write permission on pull requests and both only add labels that already exist.

legal90 · 2025-01-28T11:05:31Z

@bodgit Yes, I confirm that too. At least up until ~December 2024 (not 100% sure the exact date) the missing label would be auto-created in the repository. But that doesn't happen anymore.
It seems that this is a change of GitHub API behavior, and it is not related to the caller's permissions.

bodgit · 2025-01-29T14:25:19Z

I've just noticed that labels are being automatically created again, at least for me anyway.

syaghoubi00 · 2025-01-30T20:29:35Z

@bodgit the labels are working again for me too.

The release-please versions are unchanged, so as others suspected, it must have been on GH's end.

I still think the issue should be left open though -- even though the labels are working again. release-please was not correctly verifying that the labels were added. I'm not sure if the current source code is just using the response code as a check, which may be why it was reporting that the labels were created successfully (#1074 (comment)).

syaghoubi00 added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Jan 14, 2025

hwakabh mentioned this issue Jan 22, 2025

fix(ci): release-please-action configurations hwakabh/.github#16

Merged

dy0gu mentioned this issue Jan 27, 2025

Github Release and tag is not created when merging the release PR using the Github CLI #1067

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Labels are not being correctly applied to PR using `GITHUB_TOKEN` #1074

Labels are not being correctly applied to PR using `GITHUB_TOKEN` #1074

syaghoubi00 commented Jan 14, 2025

syaghoubi00 commented Jan 14, 2025

Aaron-Ritter commented Jan 15, 2025 •

edited

Loading

axieum commented Jan 16, 2025

Aaron-Ritter commented Jan 16, 2025

axieum commented Jan 16, 2025

looztra commented Jan 16, 2025

looztra commented Jan 16, 2025

Aaron-Ritter commented Jan 16, 2025 •

edited

Loading

Aaron-Ritter commented Jan 16, 2025

ipauldev commented Jan 16, 2025 •

edited

Loading

looztra commented Jan 16, 2025

looztra commented Jan 16, 2025

mancinifprom commented Jan 17, 2025

henrikig commented Jan 17, 2025

penalbaxplor commented Jan 23, 2025

UnP1u9 commented Jan 24, 2025

bodgit commented Jan 27, 2025 •

edited

Loading

Aaron-Ritter commented Jan 27, 2025 •

edited

Loading

syaghoubi00 commented Jan 27, 2025

Aaron-Ritter commented Jan 27, 2025 •

edited

Loading

dy0gu commented Jan 27, 2025 •

edited

Loading

Aaron-Ritter commented Jan 28, 2025

bodgit commented Jan 28, 2025

legal90 commented Jan 28, 2025 •

edited

Loading

bodgit commented Jan 29, 2025

syaghoubi00 commented Jan 30, 2025

Labels are not being correctly applied to PR using GITHUB_TOKEN #1074

Labels are not being correctly applied to PR using GITHUB_TOKEN #1074

Comments

syaghoubi00 commented Jan 14, 2025

syaghoubi00 commented Jan 14, 2025

Aaron-Ritter commented Jan 15, 2025 • edited Loading

axieum commented Jan 16, 2025

Aaron-Ritter commented Jan 16, 2025

axieum commented Jan 16, 2025

looztra commented Jan 16, 2025

looztra commented Jan 16, 2025

Aaron-Ritter commented Jan 16, 2025 • edited Loading

Aaron-Ritter commented Jan 16, 2025

ipauldev commented Jan 16, 2025 • edited Loading

looztra commented Jan 16, 2025

looztra commented Jan 16, 2025

mancinifprom commented Jan 17, 2025

henrikig commented Jan 17, 2025

penalbaxplor commented Jan 23, 2025

UnP1u9 commented Jan 24, 2025

bodgit commented Jan 27, 2025 • edited Loading

Aaron-Ritter commented Jan 27, 2025 • edited Loading

syaghoubi00 commented Jan 27, 2025

Aaron-Ritter commented Jan 27, 2025 • edited Loading

dy0gu commented Jan 27, 2025 • edited Loading

Aaron-Ritter commented Jan 28, 2025

bodgit commented Jan 28, 2025

legal90 commented Jan 28, 2025 • edited Loading

bodgit commented Jan 29, 2025

syaghoubi00 commented Jan 30, 2025

Labels are not being correctly applied to PR using `GITHUB_TOKEN` #1074

Labels are not being correctly applied to PR using `GITHUB_TOKEN` #1074

Aaron-Ritter commented Jan 15, 2025 •

edited

Loading

Aaron-Ritter commented Jan 16, 2025 •

edited

Loading

ipauldev commented Jan 16, 2025 •

edited

Loading

bodgit commented Jan 27, 2025 •

edited

Loading

Aaron-Ritter commented Jan 27, 2025 •

edited

Loading

Aaron-Ritter commented Jan 27, 2025 •

edited

Loading

dy0gu commented Jan 27, 2025 •

edited

Loading

legal90 commented Jan 28, 2025 •

edited

Loading