Conversation
There was a problem hiding this comment.
Pull request overview
This PR targets two FoD CLI edge cases: preventing microservice creation for non-microservice applications (issue #873) and ensuring DAST Automated scans can start on a newly created/configured release with no prior scans (issue #917).
Changes:
- Add a microservice-enabled check to short-circuit microservice creation attempts on non-microservice applications.
- Adjust DAST Automated scan start flow to avoid “in progress” handling when a release has no prior scans.
- Expose
FoDScanHelper.getEmptyDescriptor()for reuse by scan-start logic.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/microservice/cli/cmd/FoDMicroserviceCreateCommand.java | Avoids creating microservices on apps that aren’t microservice-enabled by returning an action result instead. |
| fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/dast_scan/cli/cmd/FoDDastAutomatedScanStartCommand.java | Adds a pre-check intended to prevent waiting/looping behavior when starting the first DAST scan on a release. |
| fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/_common/scan/helper/FoDScanHelper.java | Makes getEmptyDescriptor() public to support the new DAST scan start pre-check. |
Comments suppressed due to low confidence (1)
fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/microservice/cli/cmd/FoDMicroserviceCreateCommand.java:58
- When the target application is not microservice-enabled, this command now returns the application descriptor with
__action__=NOT_MICROSERVICE_ENABLEDand exits successfully. That differs from issue #873’s expected behavior (error) and is also inconsistent with other microservice flows likeFoDMicroserviceHelper.getAppDescriptor()which throws for non-microservice apps, so callers/pipelines may proceed assuming the microservice exists.
Consider throwing a user-facing exception by default (with a clear message), or introducing an explicit opt-in flag to make this a non-fatal/skip behavior.
// if the application is not microservice enabled, return the application descriptor with an additional field indicating that the microservice was not created due to the application not being microservice enabled
if (!appDescriptor.isHasMicroservices()) {
return appDescriptor.asObjectNode().put("__action__", "NOT_MICROSERVICE_ENABLED");
}
| // check if there have been any scans previously run for this release | ||
| if (!FoDScanDastAutomatedHelper.getLatestScanDescriptor(unirest, relId, FoDScanType.Dynamic, true) | ||
| .equals(FoDScanHelper.getEmptyDescriptor())) { | ||
|
|
||
| if (scan != null && scan.getAnalysisStatusType().equals("In_Progress")) { | ||
| if (inProgressScanActionType.getInProgressScanActionType() == FoDEnums.InProgressScanActionType.DoNotStartScan) { | ||
| scanAction = "NOT_STARTED_SCAN_IN_PROGRESS"; | ||
| return scan; | ||
| // if there is an in progress scan, handle according to the specified action type | ||
| FoDScanDescriptor scan = FoDScanDastAutomatedHelper.handleInProgressScan(unirest, releaseDescriptor, | ||
| inProgressScanActionType.getInProgressScanActionType(), progressWriter, maxAttempts, | ||
| waitInterval); | ||
|
|
||
| // if the action was to not start a new scan, return the in progress scan descriptor | ||
| if (scan != null && scan.getAnalysisStatusType().equals("In_Progress")) { | ||
| if (inProgressScanActionType.getInProgressScanActionType() == FoDEnums.InProgressScanActionType.DoNotStartScan) { | ||
| scanAction = "NOT_STARTED_SCAN_IN_PROGRESS"; | ||
| return scan; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
The new guard uses FoDScanDastAutomatedHelper.getLatestScanDescriptor(...Dynamic...) to decide whether to call handleInProgressScan(), but getLatestScanDescriptor() filters out analysisStatusType=In_Progress. If a release only has an active/in-progress scan (e.g., the very first scan is currently running), this condition will evaluate as “no previous scans”, skip the in-progress handling entirely, and then attempt to start a new scan.
A more reliable fix is to handle the “no scans exist yet” case inside handleInProgressScan() (return null immediately when the scan list is empty) or change this check to detect whether the release scan list is empty without excluding active scans.
Gracefully handles create of microservices when not a microservice application (fixes #873)
Fixes DAST Automated scans now starting on a newly created/configured release (fixes #917)