Existing releases cannot be promoted after a project is converted to config as code

[ryanrousseau]

Team

• [X] I've assigned a team label to this issue

Severity

So far only reported internally

Version

2022.4 (Build 1372-hotfix.2686) - wasn't present a week or so ago so seems to be new

Latest Version

No response

What happened?

Update - further testing shows that this isn't related to the export/import but caused by converting the project to config as code after the import.

I've also confirmed this by creating a brand new non-cac project, deploying a release, converting to cac, and trying to promote the existing release.

The error is 405 method not allowed on the deployment settings endpoint.

Reproduction

1. Create a project that doesn't use cac
2. Create a release and deploy it
3. Convert the project to cac
4. Try to promote the existing release to the next environment
5. See the error attached above

Error and Stacktrace

No response

More Information

No response

Workaround

None found yet

[StephenHeise]

@OctopusDeploy/team-config-as-code Here is what is going on.

1. We have a CaC project, but the previous release was a database release (done before the project was converted to CaC).
2. The user tries to promote the release to the next environment / life cycle phase.
3. In ~\components\Releases\Deployments\Create.tsx, line 221, it tries to get the Git ref from the previous release: const gitRefResource = release.VersionControlReference?.GitRef ? await repository.Projects.getGitRef(this.props.projectContext.state.model, release.VersionControlReference.GitRef) : undefined;
4. This is going to be undefined, because the previous release was a database release.
5. Then it tries to get the deployment settings, passing in undefined for the gitRefResource: const projectContextRepository = new ProjectContextRepository(client, this.props.projectContext.state.model, gitRefResource);
6. The DeploymentSettingsRepository sees that it is a Git project, so tries to use the Git endpoint passing nothing for the Git ref.
7. Server says nope - 💥

The question is, what is the expected behaviour here?

• We could get the deployment settings from the database (at least I assume we can). That might not be what the user expects if they have just converted the project to CaC.
• We could get the deployment settings from the default Git branch, however, there could be changes on the branch since the last release, so there is no guarantee that the release is safe to promote.
• Block the release promotion. Force the user to create a new release.

[shipra-octopus]

I am surprised that we only hit this now. I would have thought customers would have hit this before? But maybe they have but haven't reported it?

In any case, if there is little or no customer impact as of yet - we could have this sitting in the backlog for a bit.

As a user, I would expect the release promotions to continue using the DB process, settings and variables. This is because we have a philosophy of promoting consistency and ensuring nothing changes as we progress things between environments. So if suddenly refer to the latest in Git, that would introduce a change to the release in progress?

In terms of a solution, we could -

• A complicated option - When converting a project, we could attempt to internally make a note that a release is in progress and ensure nothing has been deleted from the DB for a period of time. This might be some sort of a flag. We could then check this flag at time of promoting the release to decide if we use DB version or Git version. And once a certain time has passed or release has completed its lifecycle, we delete all of this from DB. We need a time limit because releases do not always complete their full lifecycle.

• A simpler option - during the conversion or migration, we should check if there are any in-progress releases. If there are, we could warn the user that those releases cannot be progressed? Then its upto them to either ignore that or finish release lifecycle before converting to CaC.

[ryanrousseau]

@shipra-octopus I think this issue may be very new. I'm fairly sure I was able to promote old releases in a newly converted project in 2022.3.

[shipra-octopus]

@ryanrousseau Thanks for that! Appreciate it.

So wondering what has changed between the releases @StephenHeise??

[StephenHeise]

Have done a bit more digging. Previously, in this situation, the default Git branch was used to get the deployment settings. I'm not sure exactly what has been changed, but I would say some things have been tightened up around fetching the deployment settings and this error is a side-effect of that. Complicated option - Would definitely work, but would be a lot of dev. Seems like a big effort for a fairly uncommon situation. Simpler option - Seems like a reasonable approach to me. I don't think requiring a new release to be created in this situation would be too much of a burden. Like the idea of letting the user know when the convert to CaC so they can decide.

[StephenHeise]

Sized as small based on Simpler option.

[shipra-octopus]

Can we go back to the previous situation of using the default branch then? What is stopping us doing that? Not sure what this means -

tightened up around fetching the deployment settings and this error is a side-effect of that

[dan-close]

Customer report: Internal

[zentron]

Release Note: Releases created on version controlled projects before conversion will fallback to using the deployment settings from the default branch on the preview screen.

[Octobob]

:tada: The fix for this issue has been released in:

Release stream	Release
2023.1	2023.1.5518
2023.2+	all releases

[garrettdass]

Customer report in version 2022.4.8471: Internal 🎫