Add release.yml to automate release notes #16633

[OrlinVasilev]

Use github autogeneration release notes and add action to check if the PR has labels

check the Issue #16633 for full description and example repo

Complete and more readable relase notes
https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes
Signed-off-by: OrlinVasilev ovasilev@vmware.com

[codecov]

Codecov Report

Merging #16634 (27463f4) into main (a5b5e21) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #16634      +/-   ##
==========================================
+ Coverage   67.31%   67.33%   +0.01%     
==========================================
  Files         953      956       +3     
  Lines       79028    79203     +175     
  Branches     2331     2332       +1     
==========================================
+ Hits        53198    53330     +132     
- Misses      22259    22272      +13     
- Partials     3571     3601      +30     

Flag	Coverage Δ
unittests	67.33% <ø> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/lib/cache/util.go	73.68% <0.00%> (-15.79%)	⬇️
src/server/middleware/util/util.go	91.66% <0.00%> (-8.34%)	⬇️
.../portal/src/app/shared/services/project.service.ts	2.50% <0.00%> (-5.00%)	⬇️
src/server/middleware/contenttrust/cosign.go	72.72% <0.00%> (-3.94%)	⬇️
src/server/middleware/contenttrust/notary.go	69.44% <0.00%> (-3.29%)	⬇️
src/lib/cache/memory/memory.go	80.85% <0.00%> (-2.94%)	⬇️
src/server/middleware/vulnerable/vulnerable.go	93.84% <0.00%> (-2.93%)	⬇️
...t-tab/sub-accessories/sub-accessories.component.ts	74.35% <0.00%> (-1.96%)	⬇️
...te-edit-endpoint/create-edit-endpoint.component.ts	37.07% <0.00%> (-1.08%)	⬇️
src/lib/cache/redis/redis.go	58.73% <0.00%> (-0.89%)	⬇️
... and 20 more

[Vad1mo]

Great idea @OrlinVasilev 🚀 , this helps offload some repetitive tasks and give the release notes a constant structure without overhead!

[a-mccarthy]

this is great @OrlinVasilev! thanks for putting this together. I had 2 questions around process for docs and community above. I just want to make sure i understand the docs part, before approving.

I wrote up some more details around the process below, more for my own understanding :)

How this would work on an PR

• A user opens a new PR
• Once a PR is submitted, a github action will run to check if a PR has a release label
• The user or maintainer adds the correct release label to the PR (before or after the PR is created)
• Having a release label is not required before merging a PR. The github action that check labels only flags that the PR has a failed check of missing a release label.
• This check will run whenever a PR is opened, or a label is added or removed from the PR

At release time:

• When it comes time to release, a maintainer will create the release and click the built in autogenerate release option (following the steps here)
• Github will create release notes which consist of
  • The title of the PR will be pulled into release notes
  • The Github handle of the user who opened the PR will be pulled into release notes

This this correct?

Some process questions:

• At what point in the process do we make sure the PR title is ok for the release notes? When reviewing the PR? at release time, when the release notes are generated?

[OrlinVasilev]

@a-mccarthy
only one thing : Having a release label is not required before merging a PR. The github action that check labels only flags that the PR has a failed check of missing a release label.

Due to the added check, labels will be must on creating PRs otherwise the check will fail and the PR won't be able to merge!
We need to enforce that labeling to make sure: we do not forget label, we have all changes that needs to be added

As a next step we have to work on the PR Titles and to apply some good practices there as well. The title and description needs to be be part of the review process. PR should NOT be approved without well written title and description!

[a-mccarthy]

@OrlinVasilev thanks for the clarification! Do you mind creating an issue with the next steps and what else we should update? (if you dont have one already) We should also make sure to bring up the PR and review requirements in a community meeting and over slack, etc.

[a-mccarthy]

lgtm! thanks @OrlinVasilev

[OrlinVasilev]

I would love to merge that so we have 2.6 with all that in place :)

[OrlinVasilev]

BTW All labels are created so just need to assign them :)