huggingface / huggingface/diffusers

Issue Labeler fails on most bug reports: 'needs-env-info' label does not exist

Open Beginner friendly
#14,377 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
34.5k
Forks
7.3k
Avg merge
3d 3h
Merged PRs (30d)
91

Description

### Describe the bug

The `Issue Labeler` workflow fails on most new bug reports because it tries to apply a label that does not exist in this repository. It is **15 of the last 40 runs**.

The error, from run [30841049166](https://github.com/huggingface/diffusers/actions/runs/30841049166):

```
failed to update https://github.com/huggingface/diffusers/issues/14376: 'needs-env-info' not found
failed to update 1 issue
##[error]Process completed with exit code 1.
```

### Cause

`utils/label_issues.py` appends `needs-env-info` to any issue it has labelled `bug` when the body does not contain a version string:

```python
if "bug" in labels and "Diffusers version:" not in body:
labels.append("needs-env-info")
```

`needs-env-info` is listed in `VALID_LABELS`, but there is no such label in the repository — `gh label list` has `needs-code-example` and no `needs-env-info`. `.github/workflows/issue_labeler.yml` then runs `gh issue edit --add-label` per label, and `gh` exits non-zero on the unknown one, failing the step.

Two consequences:

1. Every bug report without a pasted version string fails the labeler, which is exactly the population the label was meant to catch.
2. Because the labels are applied in a loop, a failure part-way can leave the earlier labels applied and the rest not, so an issue can end up partially labelled.

### Suggested fix

The straightforward one is to create the `needs-env-info` label, since `VALID_LABELS` and `needs-code-example` both suggest it was intended to exist.

Independently of that, the apply step could avoid failing the whole job on one unknown label:

```sh
for label in $(...); do
gh issue edit "$ISSUE_NUMBER" --add-label "$label" || echo "::warning::could not apply label: $label"
done
```

That keeps a missing or renamed label from silently costing an issue the rest of its labels in future.

I am happy to open a PR for the workflow change. Creating the label itself needs repository settings access, so that one has to be on your side.

### Reproduction

Open any issue that the labeler classifies as a bug and that does not contain `Diffusers version:` in the body. #14376 is a recent example.

### System Info

Not environment-specific; CI configuration. Observed on `main` at `6f2010e8b`.

### Who can help?

@DN6 — going by `git log` on `utils/label_issues.py` and `.github/workflows/issue_labeler.yml`.

Unrelated in cause but same area, in case it is useful to look at together: #14376 is a separate CI failure in the `Secret Leaks` workflow.

Contributor guide

Open the contributing guide

Research direction

Start by reading utils/label_issues.py and .github/workflows/issue_labeler.yml, then reproduce the failure with a bug issue lacking “Diffusers version:” or inspect run 30841049166. Verify how VALID_LABELS and the per-label gh issue edit loop behave, and confirm that bug reports receive their intended labels without the job failing on needs-env-info.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, python, shell
Domain
ci-cd
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.