Tag Source on successful deployment


I have a scenario where i’d like to tag my source control repository (mercurial) after the project has been successfully deployed to a given role. I can do this in a powershell script, but i’ll need access to the revision hash that I need to tag. Teamcity has this, so when I create the release (in TC) via octo.exe, is there a way I can pass this hash along as a variable on the release, then get access to it in a post-release PS script?

Or, is there a better way?



Hi Greg,

Currently, no, there’s no way to add this variable to the release.

However, when TC invokes Octo.exe, couldn’t you use the --wait-for-completion flag to wait until the deployment completes successfully, and then have TC tag the source?


Hi Paul,

Thanks for the quick answer. I could do what you suggest yes, but we’re not auto-running the deployment from TC, just creating a release candidate in Octopus, to be run later, manually.

Is passing variables from octo on the radar for v2?

Thanks again,


Hi Greg,

We’ll give it some thought, thanks for the suggestion.

What if TC tagged the source with the release number that you use in Octopus when you call octo create-release? (E.g., release-candidate-1.0.0). Then when 1.0.0 is deployed you could look up that tag and tag it again with the deployment details?


Thanks again for the suggestion. That was my first attempt, but it doesn’t quite work in this scenario because we’re deriving release notes from developer’s commit messages.

The workflow is that a dev pushes some code with an agreed pattern in the commit messages they want picked up as release notes. The code then gets built, versioned and packaged by Teamcity, and at the same time a release notes file is generated containing all the appropriately worded commit messages from hg. The release notes contain everything on the given branch (we do branch per feature) and since the last tag (or last released version). The release notes are then passed to the release candidate on Octopus.

The problem is I need the release notes from all previous, unreleased, candidates in the latest candidate version (because not all RCs will become releases). If I tag at every commit, then my RC only gets the release notes from the push that triggered this version, and not the notes from the other, unreleased, versions.

(Bit of a ramble, hopefully that makes sense)

Would it be naive to think this is something that I could fork and test on octo.exe?



Hi Greg,

Thanks for the update, I think I understand your scenario better now.

The limiting issue here is that you won’t be able to attach the HG commit hashes anywhere (such as in a variable) even through Octo.exe, because the Octopus model doesn’t support it.

What you might be able to do is attach it to your NuGet package when the package is built (such as in the releaseNotes element in your NuSpec) and extract that during deployment. Or perhaps add it to the ReleaseNotes (you can specify a value for the release notes when calling octo.exe) of the Octopus release, and use a regex to extract it back out.


Hi Paul,

Thanks again for the help.

Sorry, i’m causing all sorts of confusion here. I’ve already got the release notes into my release candidate - in my project build script, I have a task that does something like this:

hg log -r "some incantation"  -template "{atemplate}"  -k "mykeyword" | out-file "releasenotes.txt"

and the incantation pulls out every commit matching “mykeyword” on a given branch, since the latest tag on that branch, and templates it into a nice markdown format. I then have another task which runs

octo -create-release -releasenotesfile=releasenotes.txt ...

and this works beautifully, pinning my release notes to the release in octopus exactly as expected - the issue is with the information that’s being pulled back, that is, where the latest tag is on the branch.

Because every push to source constitutes an RC, but not every RC constitutes a release, if every RC tags the commit that created it, then the next RC is only going to pick up the notes since the previous RC, and if the previous RC wasn’t released, then the notes for this RC will not be complete (apologies for the terrible explanation).

I realise i’m deviating into territory which isn’t really octopus related, and i’ve taken up a lot of your time already - so please don’t feel you have to come back and solve it for me!



Hi Greg,

I wondered if you could append the hash as the last line of the release
notes in Octopus - so your notes would be:

  • Added foo
  • Added bar

HG hash: 9a73f28e973937

Then in a script you could run a regex over the "Octopus.Release.Notes"
variable to get the last line of the release notes, and extract the hash
from that. Then you’ll be able to perform your tag against this hash during

I realize it clutters your release notes (but on the other hand, it may be
useful information to include) but it’s the only place where you can
currently add related metadata.


Paul Stovell
Octopus Deploy
W: octopusdeploy.com | T: @octopusdeploy http://twitter.com/octopusdeploy

Yes of course, sorry I follow you now. I could push it into the release notes for sure - could definitely be a useful thing to have - increases visibility and makes it easier to query back to a given commit if needed.

I’ll give that a whirl and see what happens. Is there a magic way to get my hands on the release notes, or do I need to rummage in the db for it?

Thanks a lot for the help Paul - much appreciated.


Hi Greg,

In a PowerShell script step it’s $OctopusReleaseNotes.


Excellent - thanks Paul, that should work. Thanks again for the help.