The options available for the scan-resubmit flag are too binary. Development teams have requested additional flexibility to account for the use case where an initial scan is submitted in response to a PR and you want the scan to process, but you also want subsequent commits to also be scanned to account for additional development activity, especially for larger scans.
Currently, for scan-resubmit:
When True: If a scan is active for the same project, CxFlow cancels the active scan and submits a new scan.
When False: If a scan is active for the same project, CxFlow does not submit a new scan.
Proposed solution
Introduce a new flag, say, "bounded queue," which accepts an int whose default is 0 unless explicitly defined. If 0 or not explicitly defined, then the behavior will default to the current behavior, meaning CxFlow will cancel the active scan and submit a new scan in its place. If defined to n > 0, then CxFlow will allow additional scans to be created up until n, at which point, CxFlow will cancel and then resubmit a new scan to replace the nth scan.
It can achieve this by, if bounded queue is defined, ping the queue and gauge the depth of the queue against the defined value for the project in question and then take action accordingly.
Additional details
Add any other details / contexts / screenshots about the feature request.
Describe the problem
Currently, for scan-resubmit: When True: If a scan is active for the same project, CxFlow cancels the active scan and submits a new scan. When False: If a scan is active for the same project, CxFlow does not submit a new scan.
Proposed solution
It can achieve this by, if bounded queue is defined, ping the queue and gauge the depth of the queue against the defined value for the project in question and then take action accordingly.
Additional details