Creating and Resolving Defects Using Octopus API


I’ve been using Octopus and Team City together as a build/deploy solution, and the more I use them together the more I like them. I have a lot of experience in using the TFS Build process, and used a combination of MSBuild and MSBuild to create semi-automated deployments. The web services etc were packaged up as MSI’s using WiX. I’ve posted about WiX before, and have not attempted to hide my contempt for WiX. Fortunately NuGet has come along and has all but removed the need for using WiX. Fortunately for me I am firmly ensconced in working with database deployments, and so NuGet packaging is a straightforward process.

But it’s not all gravy with database deployments: one of the big challenges with database pipelines is that you have to deploy the database in order run unit tests. This is not the case with .Net development and unit testing. So whilst a deployment may be successful, the tests may fail, so the deployment may be garbage. And if we’re using Octopus, how can we prevent a release from being promoted? By the use of Defects that’s how!

Despite being classed as a 24/7 build engineer, Team City is great as a control flow for the build/deploy/test process. Octopus have a Team City plugin available which enables you to push packages and create/promote/deploy releases. And for anything else outside that, we can use the Octopus API. And using the API is how we are going to create the defect. If we use TeamCity to run the tests post-deployment, we can trigger a chained build to report a defect on the release in question, and so prevent any further deployments until the broken test is fixed. Below is a sample script I put together to report/resolve a defect against a release. A defect will prevent a release being promoted until it is resolved.

$api = "http://localhost:83" 
$OctopusAPIKey = "API-WRWYWXVOPUFBH8YLD7KXZLTQJXS" #key from octopus

$ProjectName = "AV2014" #project name
$ReleaseVersion = "1.0.14" #build number
$header = @{ "X-Octopus-ApiKey" = $OctopusAPIKey }

$something =  @{ description = 'yet another test defect' } | ConvertTo-Json

$projectUri = "$api/api/projects/$ProjectName"

$Project = Invoke-WebRequest -Uri $projectUri -Headers $header| ConvertFrom-Json
$ProjectId = $Project.Id

$relUri = "$api/api/projects/$ProjectId/releases/$ReleaseVersion"
$ert = Invoke-WebRequest -Uri $relUri -Headers $header| ConvertFrom-Json
$red = $ert.Links.ReportDefect
$reportDefectUrl = "$api$red"

Invoke-WebRequest -Uri $reportDefectUrl -Method Get -Headers $Header | ConvertFrom-Json
Invoke-WebRequest -Uri $reportDefectUrl -Method Post -Headers $Header -Body $something | ConvertFrom-Json
 $red = $ert.Links.ResolveDefect
 $resolveDefectUrl = "$api$red"

Invoke-WebRequest -Uri $resolveDefectUrl -Method Post -Headers $header | ConvertFrom-Json 

Clearly this is not my complete example; a call to action here would be to create a check that will report a defect if one does not exist(only one defect can exist per release), or resolve if a defect does exist. And maybe tidying up some of the parameter names into something meaningful…

I’ve never worked with a REST API before, nor even JSON, but this was really easy ot put together after a bit of trial and error and looking over the samples in The Octopus API.


Author: Richie Lee

Full time computer guy, part time runner. Full time Dad, part time blogger. Knows a thing or two about Pokémon. Knows too much about SQL Agent. Writer of fractured sentences. Maker of the best damn macaroni cheese you've ever tasted.

One thought on “Creating and Resolving Defects Using Octopus API”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s