gitea
gitea copied to clipboard
Failure in Gitea API when using labeler Github action
Description
I am using actions/labeler@v5 with Gitea's Actions, the runner is running gitea/act_runner:nightly-dind-rootless, the labels are not placed on the issue & the actual workflow step is failing with the following message, added below
It's coming from the Gitea API, & i'd like to understand what how can i help to improve this.
Error:
The configuration file (path: .gitea/labeler.yaml) was found locally, reading from the file
::error::HttpError: []: json: cannot unmarshal number " into Go struct field IssueLabelsOption.Labels of type int64
::error::[]: json: cannot unmarshal number " into Go struct field IssueLabelsOption.Labels of type int64
the job looks very simple:
jobs:
labeler:
name: Labeler
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Labeler
uses: actions/labeler@v5
with:
configuration-path: .gitea/labeler.yaml
sync-labels: true
labeler.yaml
Documentation:
- changed-files:
- any-glob-to-any-file: docs/**
EDIT from gitea's log:
...eb/routing/logger.go:102:func1() [I] router: completed PUT /api/v1/repos/mariusrugan/example-repo/issues/104/labels for 1.2.3.4:37056, 422 Unprocessable Entity in 20.9ms @ v1/api.go:689(v1.Routes.func1.10.1.1.2.2.bind[...])
Many thanks in advance!
Gitea Version
1.21.11
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 container
Database
SQLite
In the GitHub API, the labels
field of the request body is an array of strings. However, in the Gitea API, the labels
field is a list of integer label IDs. actions/labeler
action uses the GitHub API so Gitea cannot parse the request correctly.
To fix this issue, we need to modify the Gitea API to make it compatible with GitHub. But this would be a breaking change.
Thanks a lot for the input,
So a fork / config flag change of the labeler action to have it working on Gitea side would be much more easy.
Maybe we can have do a compatible to accept both string and int for that field.