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.
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!
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.
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.
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.
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.
I look forward to hearing back and getting to the bottom of this one!
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.
billing-process_post-save.json (6.24 KB)
billing-process_pre-save.json (6.05 KB)
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).
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.
The projects were not migrated from another server.
The projects were created before the upgrade to 2019.12.0.
Thanks for your continuing efforts.
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!
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.
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.
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.
Thanks for the update. I verified that we upgraded from 2019.8.4 to 2019.12.0 LTS.
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?
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.
Then this one will remove the roles.
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!