Can't disable step from project that is no longer needed

[chris.ellis]

I’ve got a particular project that we are disabling a few steps in that are no longer needed. Two of the steps were able to be disabled without any issues. The third step, I’m receiving…

There was a problem with your request.

** ‘STEP NAME’ could not be disabled because it is used as part of the release creation strategy.*

First thing I checked was the release versioning and it was set to build off this step. I changed that value to another step, created a new release and pushed it to QA, but am still not able to disable this particular step. What should I check and do next? Thanks!

[brent_kinney]

Hey @chris.ellis,

Thanks for reaching out on our support forum, and welcome to the community!

Would you be able to send over some screenshots of the deployment settings for your project?

Could you also send a screenshot of your process steps?

Thanks,
Brent

[chris.ellis]

@brent_kinney

Screenshots attached. The step I’m trying to disable is Deploy BeechHill.

[brent_kinney]

Hey @chris.ellis,

Thanks for getting back to me so quickly. Your screenshots look good. You should be able to disable that step. I’ve just tried a similar setup in my local instance and could disable the step once I set the version strategy to a different package step. Can you set your release versioning back to the default and then try disabling the step?

If that works, you should then be able to set the version strategy back to the step you wish it to be based on. Hopefully, that does the trick.

Thanks,
Brent

[chris.ellis]

@brent_kinney I did that and it still fails when disabling that step.

[brent_kinney]

Hey @chris.ellis,

I believe your initial versioning strategy or process change save did not cascade properly, preventing you from disabling that step as any subsequent changes and saves are not affecting the original setting, which failed.

You could try removing any references to that step in any Channel versioning rules, as that is one area we haven’t checked yet. If that doesn’t work, you could run the below script to ‘reset’ the project.

# Create Script Variables
$octopusUrl = "https://OctopusURL"
$octopusAPIKey = "API-XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
$header = @{ "X-Octopus-ApiKey" = $octopusAPIKey }

# Case Specific Variables | Customise Lifecycle Name and Project Group if necessary.
$spaceId = "Spaces-1"
$newProjectName = "Project_For_Template"
$newProjectDescription = "Project created for version template to fix broken references. Will be deleted after."
$projectGroupName = "Default Project Group"
$lifecycleName = "Default lifecycle"

# BROKEN PROJECT ID
$brokenProjectId = "Projects-XX"

# Get Project Group Id
$projectGroup = (Invoke-RestMethod -Method Get "$octopusURL/api/$($spaceId)/projectgroups/all" -Headers $header) | Where-Object {$_.Name -eq $projectGroupName}

# Get Lifecycle Id
$lifeCycle = (Invoke-RestMethod -Method Get "$octopusURL/api/$($spaceId)/lifecycles/all" -Headers $header) | Where-Object {$_.Name -eq $lifecycleName}

# JSON Payload for template project
$jsonPayload = @{
    Name = $newProjectName
    ProjectGroupId = $projectGroup.Id
    LifeCycleId = $lifeCycle.Id
}

# Create new project
$newProject = Invoke-RestMethod -Method Post -Uri "$octopusURL/api/$($spaceId)/projects" -Body ($jsonPayload | ConvertTo-Json -Depth 10) -Headers $header

# Gather deployment settings template
$depTemplate = Invoke-RestMethod -Method Get -Uri "$octopusURL$($newProject.Links.DeploymentSettings)" -Headers $header

# Copy and modify template to match broken project
$newDepSettings = $depTemplate
$newDepSettings.Id = $newDepSettings.Id.replace($newProject.Id, $brokenProjectId)
$newDepSettings.ProjectId = $newDepSettings.ProjectId.replace($newProject.Id, $brokenProjectId)

# Determine deployment settings URL for broken project
$newUrl = $newProject.Links.DeploymentSettings.replace($newProject.Id, $brokenProjectId)

# Upload newly created default deployment settings to broken project
Invoke-RestMethod -Method Put -Uri "$octopusURL$($newUrl)" -Headers $header -Body ($newDepSettings | ConvertTo-Json -Depth 10)

# Delete Template Project
Invoke-RestMethod -Method Delete -Uri "$octopusURL/api/$($spaceId)/projects/$($newProject.Id)" -Headers $header

This script will create a new project to get a sample deployment settings from, then edit those settings to match the broken project, PUT them over the top of the failed project, and delete the newly created project from the first step.

Please, make sure you fill in the variables required with the correct name for a lifecycle and project group that exists on the space you’re targeting. You’ll also need the project ID for that project which you can get from the DB or the API/SwaggerUI.

Using the above script should solve your issue but not contain any release data as a new project is created.

I hope this helps. Let me know if you have any questions.

Regards,
Brent

[chris.ellis]

@brent_kinney I’ll try to get to this today, but will let you know once I do.

[chris.ellis]

@brent_kinney Thanks for the assist. What actually caused the problem was a trigger, total oversight on our end.

[brent_kinney]

Hey @chris.ellis,

Oh wow, I’m glad you found it, and thank you for letting me know what it was. Hopefully, the next time this happens, I can help resolve it much quicker by checking the triggers.

Regards,
Brent