Unsaved Changes dialogue always appears when clicking away from step in process

chris.x.bohling · 31 January 2020 17:47

Version 2019.12.0 LTS. The Unsaved Changes dialogue box always appears when I am viewing a step in a process and click away, even if there are no changes. For instance, if I click on Variables. My colleague and I have reproduced this in both Chrome and IE. I don’t remember this being the behavior in earlier versions.

Kenneth_Bates · 3 February 2020 06:03

Hi Chris,

Thanks for getting in touch! I’m very sorry to hear you’re hitting this unexpected issue. I’ve been unable to reproduce this behavior, however. Are you also able to reproduce this in FireFox? Do you have any other sessions in the same browser that has saved changes in this page?

To dig into this further, would you be willing to supply a recording of your reproduction, and network traffic logs as shown in the following screenshot?

You can upload them privately and securely on Octopus.com while signed in with your Octopus ID as shown below:

If you need another avenue to supply this info, let me know and I’ll be happy to generate an upload link.

I look forward to hearing back and getting to the bottom of this one!

Best regards,

Kenny

chris.x.bohling · 3 February 2020 16:55

Thanks for your response.

I realized that this behavior is happening for some steps but not most of them. The steps affected are of these types: 1) Deploy to IIS; 2) Deploy a Windows Service. Just clicking on the step, in order to view
it, results in the Save button being activated, as if there were already a change waiting. Saving the step eliminates the problem. When viewing it again, the Save button is disabled, as you would expect.

We have not changed the steps nor the projects containing them in months. We upgraded Octopus Deploy at least once since I last reviewed them.

Thanks again,

paul.calvert · 4 February 2020 01:06

Hi Chris,

It sounds like there may be some form of form auto-fill such as LastPass inserting data automatically into the fields as soon as the step is opened.

It may be useful to have a look at Configuration > Audit and filtering on document type Deployment Process to determine which values are being changed when the step is changed.

Regards,
Paul

chris.x.bohling · 4 February 2020 15:24

Paul,

Thanks for the suggestion.

In every case, what changed on the step was the “SelectionMode” property of the package. See below. The version number of the project also changed, but I take it that is due to saving the step.

Also, I discovered a “Deploy a Package” step with the same issue. It is not limited to the two step types I mentioned earlier. Still, this issue only happens for some steps; the majority are not affected.

“Packages”: [

{

“Id”: “e3fd12db-f750-4292-b1b7-035ed35f2465”,

“Name”: “”,

“PackageId”: “MobileApplicationWebApp”,

“FeedId”: “feeds-builtin”,

“AcquisitionLocation”: “Server”,

“Properties”: {

“SelectionMode”: “immediate”

}

],

Kenneth_Bates · 4 February 2020 23:38

Hi Chris,

Thanks for keeping in touch and expanding on the issue here. I haven’t had any luck reproducing this issue, and I think the best way forward would be to grab your deployment process JSON to allow an accurate reproduction attempt of your exact scenario. Would you be willing to send that through? You can download this in your deployment process page under the overflow menu as shown in the screenshot below.

If you’d prefer to send these out of this forum, you can upload it to Octopus.com while logged in with your Octopus account, or email us at support@octopus.com.

I look forward to hearing back and getting to the bottom of this one!

Best regards,

Kenny

chris.x.bohling · 5 February 2020 15:13

I had a project that was still exhibiting the behavior. I downloaded the JSON prior to saving, and then after saving. The two files are attached. There are three steps, and all of them had the Save button active.
Thanks.

billing-process_post-save.json (6.24 KB)

billing-process_pre-save.json (6.05 KB)

Kenneth_Bates · 6 February 2020 01:33

Hi Chris,

Thanks for following up and sending through that information. I’ve been able to reproduce this issue on my local instance using your deployment process JSON files. I have an idea of what could have caused this issue, which I’ll lay out below (and I’m planning on bringing this up with the engineers as it does feel like there’s some bug here).

The selection mode property on these package steps are tied into supporting the new deferred package selection feature, added in 2019.10.0 (and available in 2019.12.0 LTS). Having this property set to immediate would retain the same functionality/behavior of the package steps as you’re expecting but this property is simply required to be set. Since it’s not set on these steps, that’s what is prompting the save, and that’s the only change made for each step (so it’s safe to save these steps).

Whether there’s a bug, and where it might be depends on a bit more info. Could you confirm first if these projects have been migrated from another server? If so, did the Octopus versions match between the two?

If there was no migration, were these affected projects and package steps all created before upgrading to 2019.12.0? I’ve tested in my local 2019.12.0 instance creating a new project/package step where this property was automatically added. If this is the case, the bug would be the fact that these steps weren’t automatically updated with this property, which is annoying as you have to update each step one-by-one, and I’d need to test and reproduce this scenario specifically.

I hope that helps narrow down and clarify what’s going on! Let me know if you have any further questions, and I’ll be more than happy to help in any way I can as we move forward.

Best regards,

Kenny

chris.x.bohling · 6 February 2020 15:01

Kenny,

The projects were not migrated from another server.

The projects were created before the upgrade to 2019.12.0.

Thanks for your continuing efforts.

Kenneth_Bates · 7 February 2020 00:32

Hi Chris,

You’re quite welcome, and thanks for clarifying that. Can you also let me know which version of Octopus you upgraded from? I know the workaround is super tedious, but did saving each step that was missing this property get everything going okay for you?

I look forward to hearing back!

Best regards,

Kenny

chris.x.bohling · 7 February 2020 15:30

Kenny,

Saving each step does resolve the issue.

We upgraded a few times since I last actively reviewed these projects. I have the dates from the Audit log. Are the upgrades logged? The version was pre-October 2019.

Thanks.

chris.x.bohling · 7 February 2020 15:40

What I intended to say was that we upgraded a few times since the last time I reviewed, and modified, the projects – before this issue occurred. The version of Octopus at that time was pre-October 2019. I don’t
perform the upgrades and don’t recall the sequence.

Kenneth_Bates · 10 February 2020 01:03

Hi Chris,

Thanks for following up! Great to hear the manual saves on each step clears this up. I ran through a test setting up a project and package step in a version prior to this property being added, and then upgrading to latest, though I was still unable to reproduce this issue. Adding in that I haven’t seen this bug reported elsewhere, this will probably require a number of specific steps to reproduce which will be difficult to define. It looks like you’ve hit on some unexpected unique edge case which I might not be able to reproduce, I’m sorry to say.

The good news is this workaround will permanently fix these steps. If you’re able to find more info on your server upgrades, project history (which version it was created in), etc. I’ll be happy to run through those steps to see if I can reproduce this.

My sincere apologies about the confusion and inconvenience this issue caused. Please don’t hesitate to reach out if you have any questions or concerns going forward.

Best regards,

Kenny

chris.x.bohling · 10 February 2020 15:53

Thanks for the update. I verified that we upgraded from 2019.8.4 to 2019.12.0 LTS.

chris_mullen · 2 April 2020 04:13

I have just upgrade from 2019.6.8 to 2019.13.7 and this issue is affecting hundreds of steps for us. Has there been any progress on a solution that doesn’t involved manually saving them all?

Kenneth_Bates · 3 April 2020 04:56

Hi Chris,

Thanks for getting in touch! I’m very sorry to hear you’ve also hit this issue. Probably the easiest way to minimize the inconvenience this has caused would be to go via the API. Unfortunately I don’t have a script to address this issue specifically, but we do have some sample scripts using the Octopus.Client (an open source .NET library) which should provide a bit of a hack.

The following will add a role to each step in a project.

github.com

OctopusDeploy/OctopusDeploy-Api/blob/master/Octopus.Client/PowerShell/DeploymentProcesses/ScopeRoleToStep.ps1

# You can this dll from your Octopus Server/Tentacle installation directory or from
# https://www.nuget.org/packages/Octopus.Client/
Add-Type -Path 'Octopus.Client.dll' 

$apikey = 'API-MCPLE1AQM2VKTRFDLIBMORQHBXA' # Get this from your profile
$octopusURI = 'http://localhost' # Your server address

$projectName = "Demo project" # The name of your project
$roleName = "demo-role" # The role this step will be scoped to

$endpoint = new-object Octopus.Client.OctopusServerEndpoint $octopusURI,$apikey 
$repository = new-object Octopus.Client.OctopusRepository $endpoint

$project = $repository.Projects.FindByName($projectName) 

$deploymentProcess = $repository.DeploymentProcesses.Get($project.DeploymentProcessId)

foreach ($step in $deploymentProcess.Steps)
{
  $step.Properties.'Octopus.Action.TargetRoles' = $roleName

This file has been truncated. show original

Then this one will remove the roles.

github.com

OctopusDeploy/OctopusDeploy-Api/blob/master/Octopus.Client/PowerShell/DeploymentProcesses/RemoveRoleFromAllSteps.ps1

# You can this dll from your Octopus Server/Tentacle installation directory or from
# https://www.nuget.org/packages/Octopus.Client/
Add-Type -Path 'Octopus.Client.dll' 

$apikey = 'API-MCPLE1AQM2VKTRFDLIBMORQHBXA' # Get this from your profile
$octopusURI = 'http://localhost' # Your server address

$projectName = "Demo Project" # Name of your project
$roleToRemove = "Demo-role" # Role to remove (case sensitive)

$endpoint = new-object Octopus.Client.OctopusServerEndpoint $octopusURI,$apikey 
$repository = new-object Octopus.Client.OctopusRepository $endpoint

$project = $repository.Projects.FindByName($projectName)

$deploymentProcess = $repository.DeploymentProcesses.Get($project.DeploymentProcessId)

foreach ($step in $deploymentProcess.Steps)
{
    [System.Collections.ArrayList]$roles = $step.Properties.'Octopus.Action.TargetRoles'.Split(",")

This file has been truncated. show original

If you create a dummy target role to use for these scripts, running these should theoretically save all of the steps in the given project. I know that’s a bit ugly, but hopefully that provides a bit of an easier workaround to this issue.

Let me know how you go or if you have any further questions or concerns moving forward!

Best regards,

Kenny