Bg stop reorder #1761
Bg stop reorder #1761
Conversation
vkalapov
force-pushed
the
bg-stop-reorder
branch
7 times, most recently
from
dd016cb to
7150540
Compare
Yavor16
left a comment
Yavor16
left a comment
There was a problem hiding this comment.
Can you add also unit test for PrepareToStopDependentModulesStep
...ss/src/main/java/org/cloudfoundry/multiapps/controller/process/steps/IncrementIndexStep.java
Show resolved
Hide resolved
...va/org/cloudfoundry/multiapps/controller/process/steps/PrepareToStopDependentModuleStep.java
Outdated
Show resolved
Hide resolved
| Module applicationModule = findModuleInDeploymentDescriptor(context, getCurrentModuleToStop(context).getName()); | ||
| context.setVariable(Variables.MODULE_TO_DEPLOY, applicationModule); | ||
| CloudApplicationExtended modifiedApp = getApplicationCloudModelBuilder(context).build(applicationModule, moduleToDeployHelper); | ||
| Map<String, String> calculatedAppEnv = applicationEnvironmentCalculator.calculateNewApplicationEnv(context, modifiedApp); | ||
| modifiedApp = ImmutableCloudApplicationExtended.builder() | ||
| .from(modifiedApp) | ||
| .staging(modifiedApp.getStaging()) | ||
| .routes(getApplicationRoutes(context, modifiedApp)) | ||
| .env(calculatedAppEnv) | ||
| .build(); | ||
| context.setVariable(Variables.APP_TO_PROCESS, modifiedApp); | ||
| return StepPhase.DONE; |
There was a problem hiding this comment.
Why are you creating here new APP_TO_PROCESS here and what is the difference from the old one?
There was a problem hiding this comment.
APP_TO_PROCESS is set to the dependent app inside the subprocess. This is done due to the fact that ExecuteTaskStep relies on that variable to be set. Otherwise the logic would fail whenever a there's a need for hook executions.
...main/java/org/cloudfoundry/multiapps/controller/process/steps/SyncFlowableStepWithHooks.java
Outdated
Show resolved
Hide resolved
...ain/java/org/cloudfoundry/multiapps/controller/process/util/DependentModuleStopResolver.java
Outdated
Show resolved
Hide resolved
| completeDeploymentDescriptor.setModules(List.of(module)); | ||
| context.setVariable(Variables.DEPENDENT_MODULES_TO_STOP, List.of(module)); | ||
| context.setVariable(Variables.APPS_TO_STOP_INDEX, 0); | ||
| context.setVariable(Variables.MTA_MAJOR_SCHEMA_VERSION, 3); |
There was a problem hiding this comment.
You can add unit test for schema version 2. So you can test the validation of the version
There was a problem hiding this comment.
The reason as to why the schema version is set in this test is that when getHandlerFactory() is called it throws an exception if no version is set. Given that the schema version is already validated earlier in DependentModuleStopResolver, adding an additional check here would be redundant.
...rg/cloudfoundry/multiapps/controller/process/steps/PrepareToStopDependentModuleStepTest.java
Show resolved
Hide resolved
...st/java/org/cloudfoundry/multiapps/controller/process/steps/StopDependentModuleStepTest.java
Show resolved
Hide resolved
| <sequenceFlow id="sid-0F200B9A-6462-48CD-BA2D-6E6F1CE15D96" sourceRef="deleteIdleRoutesTask" targetRef="shouldManageServiceBroker"></sequenceFlow> | ||
| <sequenceFlow id="skipDeleteIdleRoutesFlow" sourceRef="shouldDeleteIdleRoutes" targetRef="shouldManageServiceBroker"></sequenceFlow> |
There was a problem hiding this comment.
Why did you change the location of sequence flows?
There was a problem hiding this comment.
Its changed due to the new added steps for stopping dependent modules. These specific flows should be unchanged, they've been re-ordered from the bpmn modeler.
...main/java/org/cloudfoundry/multiapps/controller/process/steps/SyncFlowableStepWithHooks.java
Show resolved
Hide resolved
LMCROSSITXSADEPLOY-3367
vkalapov
force-pushed
the
bg-stop-reorder
branch
2 times, most recently
from
d053a35 to
6e242eb
Compare
vkalapov
force-pushed
the
bg-stop-reorder
branch
from
6e242eb to
2f8b5de
Compare
|
3 participants
No description provided.