[WEBSITE-634] - Add Release Drafter configuration for drafting Weekly release YAMLs

[oleg-nenashev]

This is a follow-up to the common issues with delayed weekly release changelogs. Neither @daniel-beck nor me commit to deliver changelogs on the weekends when Jenkins weekly gets usually released, and often there are significant delays between a release and availability of changelog on https://jenkins.io/changelog/ . In order to solve the issue, I suggest using Release Drafter which has been already successfully adopted in plugins (Documentation). See WEBSITE-634 for more context.

Sample changelog YAML generated in my test environment:

Considerations:

• There is no automatic type resolution, See Add $CATEGORIES as a template variable release-drafter/release-drafter#139 for the RFE
• Release Drafter is generally not designed for YAML generation, so the implementation is quite hacky. There is Add support of generating machine-readable changelogs (YAML?) release-drafter/release-drafter#253 for better YAML support

Proposed changelog entries

• Internal: Automate drafting changelog YAMLs using Release Drafter (drafts are accessible only to Jenkins Core team members for now)
  • Changelog drafts: https://github.com/jenkinsci/jenkins/releases

Submitter checklist

• JIRA issue is well described
• Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
• Appropriate autotests or explanation to why this change has no tests
• For dependency updates: links to external changelogs and, if possible, full diffs

Wishlist

• Type resolution
• Sorting by categories: rfe, then bug and then internal
• Putting Major fixes on the top

Desired reviewers

@jenkinsci/core esp. @daniel-beck

[MarkEWaite]

I would love to see the disclaimer added that this is a preliminary change log, but even without that change it is still a good improvement.

[jglick]

Seems harmless.

Maybe we could just make https://jenkins.io/changelog/ redirect to https://github.com/jenkinsci/jenkins/releases and go all in! If we want to keep the stability voting system, perhaps it could be reimplemented as some sort of GitHub App widget embedded in the Markdown for the release (and it would make sense to extend it to plugin releases too).

[oleg-nenashev]

Maybe we could just make https://jenkins.io/changelog/ redirect to https://github.com/jenkinsci/jenkins/releases and go all in!

I would prefer to not do it in the first iteration. Can be done later once we have all machinery in WEBSITE-634 in place

[varyvol]

@oleg-nenashev seems fine, but one question: why only the last example has an associated issue but not the other ones?

[oleg-nenashev]

why only the last example has an associated issue but not the other ones?

It is how my test data is organized. Only one pull request has a fake issue ID for testing

[varyvol]

Thanks for the clarification!

[oleg-nenashev]

On hold, pending feedback from @daniel-beck

[oleg-nenashev]

@daniel-beck gentle ping

[daniel-beck]

Doesn't seem to hurt, has a chance of making things easier for us, and as long as we don't advertise it to users 🤷‍♂

[oleg-nenashev]

Thanks @daniel-beck . It will not be visible to users at all if we do not manually publish the releases