Add message about label usage in automated changelog

[kmartens27]

This PR is to add a message in the changelog styleguide Labels section, to inform readers and users that labels are necessary for the automated changelog generator to properly create the changelog. If labels are not included, the changelog generator does not recognize the pull request as part of the weekly release.

[timja]

Why not just add a GitHub action to core requiring a label?

[kmartens27]

@timja it's a good idea, I'm just looking to include this information since there have been some instances of labels not being applied and the changelog generator missing them. It looks like there is an existing action: https://github.com/actions/labeler that could be used, unless that wouldn't be an appropriate fit for one reason or another.

[MarkEWaite]

It looks like there is an existing action: https://github.com/actions/labeler that could be used, unless that wouldn't be an appropriate fit for one reason or another.

I've been using the labeler action on at least one of my repositories and I'm not sure that it is any better than no labeling. When a changeset only includes tests, then the changeset is labeled correctly with the tests label. When a change is in production code, labeler does not know if it is a bug fix or an enhancement. When a change is in one of the documentation files or in an image file, it doesn't know if it is a bug fix or an enhancement. When a change is in the pom file, it doesn't know if it is a dependency update, an upgrade of the minimum Jenkins version, a transition to CD, or something entirely different.

[zbynek]

For this issue it would be more useful to add a different action: https://github.com/marketplace/actions/require-labels . That way PRs with no lables either fail to build or get a comment.

[MarkEWaite]

For this issue it would be more useful to add a different action: https://github.com/marketplace/actions/require-labels . That way PRs with no lables either fail to build or get a comment.

But doesn't that create a barrier to new contributors and others who do not have permission to assign a label?

[timja]

For this issue it would be more useful to add a different action: github.com/marketplace/actions/require-labels . That way PRs with no lables either fail to build or get a comment.

But doesn't that create a barrier to new contributors and others who do not have permission to assign a label?

Anyone can assign a label via comment-ops. It doesn't add a barrier to them anyway, it stops the core team accidentally merging a PR thats missing a label.

[MarkEWaite]

But doesn't that create a barrier to new contributors and others who do not have permission to assign a label?

Anyone can assign a label via comment-ops. It doesn't add a barrier to them anyway, it stops the core team accidentally merging a PR that's missing a label.

So long as we describe how to add labels with comment-ops, that should be fine, though I suspect new contributors will find it a little frustrating that their first build of a new pull request will fail because they could not assign a label when creating the pull request. It seems awkward to fail a pull request build immediately for a missing label that the submitter could not create.

Will comment ops work from the initial pull request description? If so, then we could offer comments in the pull request template that recommends they choose one of the labels with comment-ops while creating the pull request.

[zbynek]

It can be also configured to post a comment and not fail the build, if that would be more useful.

[timja]

It can be also configured to post a comment and not fail the build, if that would be more useful.

i think fail it, the PR template can be updated to show people how to do it when opening the PR so it doesn't fail initially

[timja]

Will comment ops work from the initial pull request description? If so, then we could offer comments in the pull request template that recommends they choose one of the labels with comment-ops while creating the pull request.

yes it does

[timja]

Draft PR open here: jenkinsci/jenkins#10273

[timja]

Will comment ops work from the initial pull request description? If so, then we could offer comments in the pull request template that recommends they choose one of the labels with comment-ops while creating the pull request.

yes it does

I thought it did but apparently not, feature added now: timja/github-comment-ops#399

[timja]

All working, tested in jenkinsci/jenkins#10277, jenkinsci/jenkins#10278

Potential areas for improvement would be to improve the docs (changelog template, comment added in GitHub action) on when to classify it as each and when skip-changelog should be used.