Improve Deployment Sorting

ideas
1

When Architect opens a model with broken dependencies it does not always show cause of the problem in the error message.

For example the Workflow package from the Origam test model is changing the table OrigamRoleOrigamApplicationRole which was created by a script from the Security package. The Workflow package does not reference the Security package, it references Root Menu which in turn references Security.

This problem can currently only be solved by manually changing the dv:deploymentDependenciesCsv element in the DeploymentVersion xml. One can easily create an unfeasible version dependency which is then not properly explained in the resulting error message in architect. This is the error message when I put the wrong Root packege version to the deployment version Workflow 1.1.0:

Deployment version order could not be determined, because circular
dependencies were detected among some deployment versions.
Successfully ordered deployment versions:
Root 0.10
Root 0.20
Root 0.30
Root 0.39
Root 1.1
Root 4.0
Root 4.1
Root 4.2
Root 4.3
Root 4.4
Root 4.5
Root 4.6
Root 4.7
Root 4.8
Root 4.9
Root 4.9.1
Root 4.9.2
Root 4.10
Root 4.11
Root 4.12
Root 4.13
Root 4.14
Root 4.15
Root 4.16
Root 4.17
Root 4.18
Root 4.19
Root 4.20
Root 4.21
Root 4.22
Root 4.23
Root 4.24
Root 4.25
Root 4.26
Root 4.27
Root 4.28
Root 4.29
Root 4.30
Root 4.31
Security 0.50
Security 0.55
Security 1.000
Security 1.1
Security 2.0
Security 2.1
Security 2.2
Security 2.3
Security 2.4
Security 2.5
Security 2.6
Security 2.7
Security 3.0
Security 3.1
Security 3.2
Security 3.3
Security 3.4
Security 3.5
Security 3.6
Security 3.7
Security 3.8
Root Menu 0.1.0
Root Menu 0.2.0
Root Menu 1.0.0
Root Menu 1.1.0
Root Menu 1.2.0
Root Menu 1.2.1
Root Menu 1.2.2
Root 5.0
Security 5.0
Root Menu 1.2.3
Root 5.0.2
Security 5.1
Security 5.2
Chat 1.0.0
Root 5.1.0
Api 1.0.0
Root 5.1.1
Root 5.1.2
Security 5.2.1
Attachments 1.0.0
Audit 1.0.0
Widgets 1.0.0
Widgets 1.1.0
Widgets 1.2.0
Widgets 1.3.0
Widgets 1.4.0
Security 5.3
Widgets 1.5.0
Security 5.3.1
Widgets 1.5.1
Widgets 1.5.2
Widgets 1.5.3
Root 5.1.3
Root 5.1.4
Chat 1.0.1
Root 5.1.5
Root 5.1.6
Root 5.1.7
Root 5.1.8
Security 5.3.2
Widgets 1.5.4
Root 5.1.9
Security 5.4
Root 5.1.10
Root 5.2
Security 5.4.1
Root 5.3
Root 5.3.1
Widgets 1.5.5
Widgets 1.5.6
The sorting process failed with these deployment versions as the next step candidates:
Candidate: Root 5.3.2
	Dependencies:
		Root 5.3.1
Candidate: Security 5.4.2
	Dependencies:
		Root  5.3.3
		Security 5.4.1
Candidate: Root Menu 1.3.0
	Dependencies:
		Root  5.4.0
		Security  5.4.5
		Root Menu 1.2.3
Candidate: Workflow 1.0.0
	Dependencies:
		Root  5.4.0
		Security  5.4.5
Candidate: Documentation 1.0.0
	Dependencies:
		Root  5.3.3
Candidate: Widgets 1.5.7
	Dependencies:
		Root  5.3.3
		Security  5.4.4
		Root Menu  1.2.3
		Documentation  1.0.0
		Chat  1.0.1
		Api  1.0.0
		Attachments  1.0.0
		Audit  1.0.0
		Widgets 1.5.6

As you can see the message suggests that the Root package can be upgraded to the next version and the Workflow 1.1.0 is not mentioned at all.

The error message should be fixed.

It is not clear how did the Workflow package deployments end up with the incomplete dependencies. That bit could not be reproduced.

2
Release Notes 2025.10
3

The error message was extended with this to explain the problem encountered in the case described above.

The following deployments would not be able to run later because they
depend on other deployments from the current step. That is why the sorting cannot progress any further.
Blocker: Workflow 1.1.0
	Dependencies:
		Root 5.3.1
4

Would it be possible to include any hints about what the user is supposed to do now?

5

Yes, but it would be even better to add a deployment dependency editor first

Right now the user has to edit dv:deploymentDependenciesCsv element in the .origam file manually.

6

Then I propose including this in the error message. Including as much information as possible (e.g. what they should delete or include etc. – in the example case – should they remove 5.3.1 reference from somewhere?).

7

I have added this to the end of the message:

The deployment dependencies are broken. The only way to fix them now is to examine the individual deployment scripts in Architect, determine the correct execution order, and then update the deploymentDependenciesCsv elements in the respective .origam files of the conflicting DeploymentVersions.

1 Like
8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.