jenkins-infra / interesting-category-action

Validate that the next draft release is interesting
MIT License
1 stars 3 forks source link

Mechanical enforcement of category labels #1

Open jglick opened 2 years ago

jglick commented 2 years ago

People frequently forget to add an appropriate category label (chore, enhancement, etc.) to a PR before merging. This results in an uncategorized PR being left at the top of the draft release, and prevents the logic in this action from properly triggering automatic releases.

Find or create a GH Action which would add a failing check (?) to a PR if it lacks a label, ideally also verifying that the label is in the set recognized by Release Drafter. Add a corresponding workflow to https://github.com/jenkinsci/.github/tree/master/workflow-templates.

Alternately, edit this action to fail if there are any uncategorized PRs in the draft release. Thus at least you would be notified of the problem before a CD release is published with poor release notes. Not as nice because in that case you would need to not only edit labels on the PR after it has been merged but also manually trigger the release; and there would also not be any clear notification to repository maintainers that there was a problem, other than lack of recent releases, unless they specifically looked at the Actions tab.

TobiX commented 2 years ago

Would something like the following actions help?

I saw an enforcement action in the allure framework:

jglick commented 2 years ago

Would something like the following actions help?

No, this is about enforcing that a human added a label, not trying to guess at one.

https://github.com/zwaldowski/match-label-action looks like it might do what we need. The idea is to verify that at least one (or exactly one) of the labels mentioned in https://github.com/jenkinsci/.github/blob/f1a34987f2919f039282a13b8741e3c463d18bc6/.github/release-drafter.yml#L9-L55 is present. If not, the PR should be marked as in error, so not mergeable until the label is applied. (And the error mark should be cleared when that label is applied, without requiring a new push or whatever, so acc. to https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#pull_request the workflow would need to be configured with at least labeled.)

jglick commented 1 year ago

or https://github.com/mheap/github-action-required-labels

jglick commented 1 year ago

Example:

name: Check labels
on:
  pull_request:
    types:
    - opened
    - reopened
    - synchronize
    - labeled
    - unlabeled
jobs:
  labels-check:
    runs-on: ubuntu-latest
    steps:
    - uses: mheap/github-action-required-labels@v4.0.0
      with:
        mode: minimum
        count: 1
        labels: "bug, enhancement, …"
        message: "Please add at least one of the following labels: bug, enhancement, …"

Needs to be packaged in https://github.com/jenkinsci/.github/tree/master/workflow-templates using https://github.com/jenkins-infra/github-reusable-workflows/tree/main/.github/workflows if necessary to minimize per-repo maintenance (though it is pretty short as is); and https://www.jenkins.io/doc/developer/publishing/releasing-cd/#configure-cd-workflow needs to be updated to reflect that.