After modifying a Step Template and trying to update it for the ~60 projects that use it, I receive this error when trying to Update All: “Resource is not found or it doesn’t exist in the current space context. Please contact your administrator for more information.”
This seems to be related to a version controlled project that previously used this Step Template but the master branch no longer does and the old branch has been deleted. When looking at the Usage for the Step Template, it still lists the project with a specific release and the deleted branch.
How do we disassociate the Step Template from the project that is no longer using it or otherwise resolve this error that it is preventing us from updating all of the non-version controlled projects?
Thanks for reaching out and welcome to the Octopus forums.
I believe you’re going down the right path there with your investigation. This is likely due to the release that still exists that has the step template associated with it. Due to the nature of how Octopus treats releases, it has to hang onto everything that it needs in the event that you need to re-deploy that release in the future. Is that a release you need to keep? If not, can you try deleting it and see if the association goes away from your step template with that project?
Thank you, deleting the release did remove the step template association. Is this the only way to remove this association? Alternatively, is there a way to only update step templates for projects that are not version controlled, to avoid this error when old branches get deleted?
Yes that is the only way to remove the association. It has to keep it as long as a release that used it exists, because if you tried to deploy that release without that association it wouldn’t work anymore.
There’s no way to do it inside the portal, but you could create a runbook that you run to update the step template usage and do some automation on checking if the project is CaC and if so, also check if the step template is part of any active branches. It’s a bit of a hacky workaround but it would make the process smoother. I’m going to pass this along to our Config as Code team and make sure they’re aware of this as I feel this could potentially be handled in product.
Here is a script you could start with and adapt to do the above if you feel like that’s a path you want to go down:
$octopusUrl = "https://octopusURL"
$octopusAPIKey = "API-XXXXXXXXXXXXXXXXXXXXXX"
$header = @{ "X-Octopus-ApiKey" = $octopusAPIKey }
$spaceId = 'Spaces-XXX' # The Spaces-XXX ID of the space (this can be found in the URL for any page on the space)
$templateId = "ActionTemplates-XXX" # The ActionTemplates-XXX ID of the step template (this can be found in the URL of the step template, within Library -> Step Templates)
$update = ""
$json = Invoke-RestMethod -Method Get -Uri "$($octopusUrl)/api/$($spaceId)/actiontemplates/$templateId" -headers $header
$latestVersionNumber = $json.version
write-host "Latest Version number is $($latestVersionNumber)"
$items = Invoke-RestMethod -Method Get -Uri "$($octopusUrl)/api/$($spaceId)/actiontemplates/$templateId/usage" -headers $header
Foreach ($item in $items) {
if ($item.Version -lt $latestVersionNumber) {
$payload = @"
{“ActionsToUpdate":[{"ProcessId":"$($item.processid)",”ProcessType":"$($item.processtype)","ActionIds”:["$($item.actionid)"],”GitRef":""}],"Overrides":{},"DefaultPropertyValues":{},"Version”:"$($latestVersionNumber)"}
"@
$update = Invoke-RestMethod -Method Post -Uri "$($octopusUrl)/api/$($spaceId)/actiontemplates/$($templateId)/actionsUpdate" -header $header -body $payload
write-host "Updating step template on project $($item.processid) outcome: $($update.Outcome)"
}
}
Please let me know if that helps or if you have any questions or concerns.