release changelog automation #824
Conversation
🔍 Preview links for changed docs |
| import java.util.regex.Matcher; | ||
| import java.util.regex.Pattern; | ||
|
|
||
| public class ReleaseChangelog { |
There was a problem hiding this comment.
[for reviewer] almost copied as-is from apm-agent-java with minor tweaks to handle the lack of previous version.
| Lines dependenciesNotes = nextChangelogLines.cutLinesBetween("<!--DEPENDENCIES-NOTES-START-->", | ||
| "<!--DEPENDENCIES-NOTES-END-->"); |
There was a problem hiding this comment.
[for reviewer] this section does not exists in the next release changelog template, we have to append it manually at runtime. This is due to the fact that we can't easily invoke the gradle task from here, doing everything from gradle in the future would simplify this.
| # note: release notes here will be copied as-is from 'CHANGELOG.next-release.md' | ||
| # the 'pre-post-release' workflow executed after this will reset contents of 'CHANGELOG.next-release.md' |
There was a problem hiding this comment.
[for reviewer] here the github release changelog needs to be in pure markdown, so we can't append our custom markdown from breaking changes.
| % * | ||
|
|
||
| # 1.5.0 [edot-java-1.5.0-release-notes] | ||
| ## 1.5.0 [edot-java-1.5.0-release-notes] |
There was a problem hiding this comment.
[for reviewer] this made the changelog generation not properly detect the previous version.
|
Interesting! For now, we don't use have Known issues / Breaking changes pages for EDOT Java, but those could eventually be filled out. Does this PR account for that possibility? Does it produce a PR we can review before merging? And, if we edit the PR, would subsequent runs override the content? A more general approach for release notes automation is in the works (+CC @alexandra5000 @lcawl @colleenmcginnis ). While I think it's totally fine to implement some automation right now, I guess we might want to align in the future. |
jackshirazi
left a comment
jackshirazi
left a comment
There was a problem hiding this comment.
lets try and see, we can fix anything broken afterwards
|
@theletterf we do have breaking changes after this release |
|
@jackshirazi @SylvainJuge When that happens, we'll have to use https://github.com/elastic/elastic-otel-java/blob/main/docs/release-notes/breaking-changes.md |
| echo '<!--DEPENDENCIES-NOTES-START-->' >> CHANGELOG.next-release.md | ||
| echo -e "This release is based on the following upstream versions:\n\n" >> CHANGELOG.next-release.md | ||
| ./gradlew -q printUpstreamDependenciesMarkdown >> CHANGELOG.next-release.md | ||
| echo '<!--DEPENDENCIES-NOTES-END-->' >> CHANGELOG.next-release.md |
There was a problem hiding this comment.
what's the reason those headers/bottom are not also generated by printUpstreamDependenciesMarkdown?
There was a problem hiding this comment.
printUpstreamDependenciesMarkdown is also used to generate the github release markdown, which should not include those, again this is a shortcut and I'll create an issue with all the things we could improve here.
This PR just tries to fills what we currently have in the changelog, I think that having a more structured approach later is needed: for example a yaml description of changes that we can output in multiple markdown variants, for now it's mostly copy-pasta markdown.
Is there already an existing issue to track progress and requirements here ? On our side we need:
For example, the way to handle changes in otel semconv is quite interesting with a tool called |
4 participants
Fixes #692
This is a first step to improve release automation, there are definitely rough edges and future improvements will be necessary. In particular, it adds an
DEPENDENCIES-NOTESsection at runtime to include the dependencies versions. In the future maybe managing everything within gradle would be cleaner and more reliable.We can test it locally for the release 1.6.0 in the current state of main by running the following commands: