Thanks Erik, I really like the temp file idea, very clean.

I’ve toyed with the idea of generating a changelog of commits between releases, but it feels to me like it would have to be done at deploy time rather than build time – you could have multiple builds that get deployed (e.g. to test environments) between actual releases to production, and a change log would need to take into account all of them. It’s something I’ll try to follow up with a blog on.

Thanks for the comment!

Then, in your build step, use the parameter: /p:OctoPackReleaseNotesFile=%system.teamcity.build.tempDir%\releasenotesfile_%teamcity.build.id%.txt

However, doing all this means that each package you deploy will have its own copy of the build steps, and the release itself won’t have the release notes (this is a drawback because the Overview page only shows the release-level release notes, not any package-level release notes, at least with more than one package as I can’t confirm what happens with one package).

Furthermore, see Generating a project change log with TeamCity and Powershell for a script that makes a much grander set of release notes, including all commits since the last build (or release? not sure). I souped it up to include the commit sha, with a link back to the source control web site’s commit page. I also plan to update the script to add links to anything that looks like a case reference back to my project management software. And finally, I plan to use the committer’s user name when TeamCity hasn’t yet been told which TeamCity user that committer actually is (do this in your user profile).

Last, if you accept building a new release every time you build, then add a TeamCity step, “OctopusDeploy: create release”, and in the additional command line arguments, put

--releasenotesfile="%system.teamcity.build.tempDir%\releasenotesfile_%teamcity.build.id%.txt"

This makes the Overview page in Octopus awesome!