Skip to content

Add phase-configs support to Hook model for target-app resolution#1812

Merged
IvanBorislavovDimitrov merged 13 commits into
cloudfoundry:masterfrom
stiv03:feature/hook-phase-target-app
May 13, 2026
Merged

Add phase-configs support to Hook model for target-app resolution#1812
IvanBorislavovDimitrov merged 13 commits into
cloudfoundry:masterfrom
stiv03:feature/hook-phase-target-app

Conversation

@stiv03
Copy link
Copy Markdown
Contributor

@stiv03 stiv03 commented Apr 3, 2026

@stiv03 stiv03 marked this pull request as draft April 3, 2026 08:17
@stiv03 stiv03 marked this pull request as ready for review April 8, 2026 12:08
@stiv03 stiv03 force-pushed the feature/hook-phase-target-app branch from 20deee7 to 0827e89 Compare April 20, 2026 08:15
stiv03 added 4 commits April 20, 2026 11:22
…reen deployments

Route hook task execution to idle or live app based on phase-configs in the hook
descriptor. Pass idleMtaColor, liveMtaColor, subprocessPhase and phase variables
to all hook call activities in BPMN processes. Add determineDeploymentTypeSafely
to avoid SERVICE_ID lookup failures in hook subprocesses.

# Conflicts:
#	pom.xml
buildCurrentPhaseString was always picking the first phase from hook.getPhases(),
causing wrong target-app resolution when a hook registered for multiple phases fired
during a later phase. Also fixed getDeploymentTypeString returning "deploy" instead
of "blue-green" inside hook subprocesses where SERVICE_ID is absent.

Introduced HOOK_EXECUTION_PHASE variable set by HooksExecutor to record which phase
triggered the current hook execution. ExecuteTaskStep now matches against this value
to find the correct phase-config entry. Variable is passed to all hook call activities
in deploy-app, undeploy-app, backup-existing-app and stop-dependent-modules BPMNs.
@stiv03 stiv03 force-pushed the feature/hook-phase-target-app branch from 0827e89 to c5bab3b Compare April 20, 2026 08:26
@stiv03 stiv03 force-pushed the feature/hook-phase-target-app branch from c5bab3b to 9165d29 Compare April 20, 2026 08:30
@stiv03 stiv03 force-pushed the feature/hook-phase-target-app branch from 13a5600 to 7deb07c Compare May 7, 2026 07:43
Comment on lines +43 to +66
private String resolveTargetAppName(ProcessContext context, CloudApplicationExtended app) {
Hook hook = context.getVariable(Variables.HOOK_FOR_EXECUTION);
if (hook == null) {
return app.getName();
}

List<Map<String, String>> phasesConfig = getPhasesConfig(hook);
if (phasesConfig.isEmpty()) {
return app.getName();
}

String currentPhase = buildCurrentPhaseString(context, hook);
String targetApp = phasesConfig.stream()
.filter(config -> currentPhase.equals(config.get(PHASE_KEY)))
.map(config -> config.get(TARGET_APP_KEY))
.findFirst()
.orElse(null);

if (targetApp == null) {
return app.getName();
}

return resolveAppNameForTarget(context, app, targetApp);
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small refactoring suggestion: app.getName() is returned in multiple branches here. Consider assigning it as the default result and only changing it when a target app is found, to reduce repetition.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suggested refactoring would work if resolveAppNameForTarget always returns a non-null value, but resolveLiveAppName returns null as a sentinel to signal that the hook execution should be skipped (initial deploy, no live app exists). Using Optional.map() with a lambda that can return null throws a NPE.

@IvanBorislavovDimitrov IvanBorislavovDimitrov merged commit 53e6e56 into cloudfoundry:master May 13, 2026
4 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants