We are using TFS to build solution, package, push it to Octopus and create release.
I would like to merge the release notes file from solution and auto generated release notes from Create Release functionality of the TFS plug in (containing changesets, work items, etc.)
If I specify --releaseNotesFile argument, the resulting release notes in Octopus missing the entire work items and changesets section. Is there any way to merge our file with the autogenerated one?
Thanks for getting in touch. There is currently no first class concept like this in our plugin. I haven’t actually tried it, but an option that comes to mind is to utilize the
Custom Notes field on the create release step, because I believe that will get included with the other content. So if you had a custom script step before the create release step you might be able to get it to read the file content and put it into an output variable, then bind the Custom Notes to that output variable from the previous step.
We’ve been doing some work in this area recently too, related to package metadata and pushing more information about the build and work items to Octopus in a slightly different way that is compatible with all of our build server plugins (TeamCity, Bamboo etc). We’d be really keen to understand how you use this file to pass release notes from the source code, it’s something we’ve been asked about by a couple of times and we want to make sure we understand the usage scenario before we try to design/build something. E.g. do you build the custom release notes by editing that file during the development?
Unfortunately, the Custom Notes field strips down any markdown aside from URL formatting. The most notable is the due to the one line nature of this input field, we lose line breaks, making the Release Notes less readable.
We fill out Release Notes file manually, storing the requirements and most notable changes there. We use md format for this file, so it should look nice wherever this format is supported.
Hi Dennis, thanks for the additional information, that use case makes a lot of sense and we’re looking into what we might be able to do to support it.
As I mentioned, we’ve been doing a lot of work in this area recently and updating all of our build server plugins to support some new features for getting build/package metadata into Octopus. The Azure DevOps changes for that are almost complete and should be shipping fairly soon. We’d most likely be looking to deprecate the existing functionality at that point and probably implement support for this feature in the new Package Metadata step. One of the advantages of this is that the release note information is tied to the package you built and not the release you created. So say you had to create another release using the same packages versions for some reason, you would get the same release note details because they are coming with the package(s). Another scenario might be if your build process consisted of multiple packages, each could have it’s own markdown file in the source code and you add the Package Metadata step for each package, then you get a many to one between release notes and a release.
I hope that makes sense, if you have any questions please let me know and please check out the new step features once they are release and let us know what you think.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.