Skip to content

Pipeline changes to generate and post release with release notes.#65

Open
akhanzode wants to merge 1 commit intomainfrom
release-post-changelog-generator
Open

Pipeline changes to generate and post release with release notes.#65
akhanzode wants to merge 1 commit intomainfrom
release-post-changelog-generator

Conversation

@akhanzode
Copy link
Copy Markdown
Collaborator

No description provided.

script: """
git log ${previousTag}..${params.TAG} --pretty=format:'* %s ([%h](https://github.com/VoltDB/volt-testcontainer/commit/%H))' --no-merges || echo ""
"""
).trim()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to strip out any ENG-xxxxx[:] or Eng-xxxxx[:] prefixes from the commit messages.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats why I have a option where pipeline can add custom message without tickets and commit logs.
This will allow us to provide our own message to post in release note.

@benjaminballard
Copy link
Copy Markdown
Contributor

benjaminballard commented Mar 24, 2026

I've thought about this and ultimately I don't see the value over using Github's auto-generated Release Notes. The formatting is very similar. I asked Claude to mock-up what they would look like.

This PR's Jenkins-generated approach:

`

Release v1.9.0

What's Changed

Full Changelog: v1.8.0...v1.9.0
`

Note that the Pull Requests section would not even appear because there are no traditional merge commits, all PRs are squash-merged.

Github auto-generated:

`

What's Changed

Full Changelog: v1.7.0...v1.8.0
`

In either case, someone will need to edit the generated notes to remove ENG-xxxxx ticket numbers, omit test or process-oriented changes, and reword the commit messages (that weren't intended to be release notes).

We can edit either way, whether we use the built-in Github auto-generation or this code, but if we just used Github, there's less code to maintain and less complexity during the release process, so I'm not seeing the value in doing this.

@akhanzode
Copy link
Copy Markdown
Collaborator Author

I've thought about this and ultimately I don't see the value over using Github's auto-generated Release Notes. The formatting is very similar. I asked Claude to mock-up what they would look like.

This PR's Jenkins-generated approach:

`

Release v1.9.0

What's Changed

Full Changelog: v1.8.0...v1.9.0
`

Note that the Pull Requests section would not even appear because there are no traditional merge commits, all PRs are squash-merged.

Github auto-generated:

`

What's Changed

Full Changelog: v1.7.0...v1.8.0
`

In either case, someone will need to edit the generated notes to remove ENG-xxxxx ticket numbers, omit test or process-oriented changes, and reword the commit messages (that weren't intended to be release notes).

We can edit either way, whether we use the built-in Github auto-generation or this code, but if we just used Github, there's less code to maintain and less complexity during the release process, so I'm not seeing the value in doing this.

See my previous comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants