Hi @rik.crompton,
I’m just jumping in for Adam and Sean as they’re offline with the UK Support team. Thanks for sending the Deployment Process OCL file through.
Our engineers working on this have successfully reproduced the same issue locally. They’ve identified that updating the step version is also triggering a schema version update from v4 to v5. The step version update process doesn’t set things up properly for the schema version update and it is failing.
This is a bug and a private issue has been created for the engineering team to get it fixed. Good news is there is a workaround in place:
- Go into the Deployment Process.
- Make a trivial change, for example, change the name of a step or add a note to it. Anything really.
- Commit the change. This should trigger the migration of the schema from v4 to v5. There should be a commit with a message ‘Octopus Schema Migration to v5’ that changes the
.octopus/schema_version.ocl file to version = 5. It may have other changes as well.
- Now the
Update and Commit button should work on the step.
- The trivial change can now be undone and committed, if required.
Our apologies for the length of time this has taken to figure out - we appreciate your on-going patience!
We will ensure to update you when the fix has been rolled out and in the short term, please let us know if you have any luck with the suggested workaround.
Kind regards,
Lauren
1 Like
Thanks for the feedback - I’ll give the workaround a try
I’ve just tried the workaround by adding some notes to two of the steps, but it didn’t help.
I’m not seeing the Schema Migration from v4 to v5.
I’m guessing that I need to be on v5 of the schema in order for the “Update & Commit” to work?
Hi @rik.crompton
The main issue is that the step version isn’t updating correctly due to that schema version being on v4 instead of v5. This is specific to the step that you’re having issues with.
Did you temporarily change that step’s name and commit that, or did you just add notes? It might be worth trying to change the name and see if that triggers the update.
Also, in your commits on your repo do you see any commit message like “Octopus Schema Migration to v5”?
Kind Regards
Sean
Hi @rik.crompton
Apologies, I put
Did you temporarily change that step’s name and commit that, or did you just add notes?
When I should have specified that it would be best to try and change one of the steps that are NOT affected, since the steps with versions are causing the issue.
Another workaround might be to try and manually update the schema_version.ocl in your repo to state version 5 instead of the one it is currently on.
Kind Regards
I updated the notes on a step that was unaffected by the “Update and Commit” issue and one that was (two separate commits). When I fetch the changes locally there is no other commit that suggests there has been an update to v5.
Note: I have seen the “Update to v4” commit that was generated by Octopus when I started making changes that gave rise to this issue, but there has been no subsequent “update to v5” commit.
Another workaround might be to try and manually update the schema_version.ocl in your repo to state version 5 instead of the one it is currently on
I’m reluctant to do this without knowing what the schema differences are between v4 and v5. I’m assuming that there would need to be changes to the process to conform with the updated schema?
For info here’s the commit history:
Hi @rik.crompton
When I fetch the changes locally there is no other commit that suggests there has been an update to v5.
It may be that the commit was potentially bundled. Is your schema version still stating version 4?
I’ll have to ask our engineer who did the fix to see if there is another workaround for you since that one doesn’t seem to be working. From my knowledge, the schema version just tells the code what to expect in the OCLs, but I’ll double-check with engineering.
Sorry that this workaround hasn’t solved the issue for you. We’ll try and get another solution ASAP.
Kind Regards
Sean
1 Like
The schema_version.ocl contains:
version = 4
Hi @rik.crompton
If that’s the case, we might want to try to change this manually to 5. Once that’s done the next commit will only change the IDs in your deployment_process.ocl file into slugs, which is the only major change that we know about.
For your previous questions on changing the process to conform with the updated schema, there isn’t anything you need to do on your side, inside or outside of Octopus. We will just automatically switch the IDs to slugs, and then it will go as normal.
Let me know if you can change this version, and then try committing a change on one of the unaffected steps.
Kind Regards
Sean
Oh. I get this when trying to access the process now:
From the browser’s dev tools I can see the error:
This repository directory contains a later version of the Git Schema than Octopus Server recognises. - Supported: 4 - Returned: 5
This is returned from a POST to https://howells.octopus.app/api/Spaces-1/projects/Projects-1/git/validate
I’m reverting the schema version change 
Reverting the schema version to 4 fixes the issue. It looks like the version of Octopus that I am on (2022.3.5513-hotfix.7091) does not yet support v5 of the schema?
Hi @rik.crompton
That looks to be the case from the error message. I can see you are on cloud, with you being in our instance ring that has 2022.3.5513-hotfix.7091. We do have another ring the majority of customers are on, which is on version 2022.3.7275-hotfix.8764.
Would you mind if we upgraded you to this next stable ring to get you access to that new schema version? It would most likely happen during your maintenance window, which would be 20:00-22:00(UTC+1), unless you wanted it to happen sooner.
Kind Regards
Sean
An upgrade would be good for us. We’re not planning any deployments today, so it can be done anytime.
One thing I note is that when comparing releases[1] an upgrade from the version we’re on to 2022.3.7275-hotfix.8764 is not supported!
Hi @rik.crompton
If it’s alright with you I’ll get that kicked off as soon as you okay the upgrade. Shouldn’t take more than half an hour or so.
The compare releases will say it’s not supported due to you going onto that particular hotfix version. The issues in that hotfix will be rolled into a more solid release and included in any later versions you are upgrading to. That warning will always persist for 2022.3.7275-hotfix.8764 until we clear it.
Kind Regards
Sean
I’ll set that running off now and let you know when its done!
Kind Regards
Sean
@rik.crompton
Your instance should be back up now. Can you test the original workaround and see if that works for you now?
Sean
