Customers may have a long-running job in their build pipeline that they want to continue to run in an external service that will route to CircleCI. Then the workflow execution should be able to be paused or stopped, and then have an external trigger that will continue the necessary workflow via API v2.
A solution meeting these criteria would be to split the existing pipeline into two workflows and make use of pipeline parameters. The external service would utilize our TriggerPipeline API with the necessary pipeline parameters to trigger the second workflow.
Here is an example configuration with pseudo-code:
# pipeline parameters
# & possibly more parameters to contain the information from the remote external service (e.g., job 2's ID, branch, etc)
cond: not << pipeline.parameters.external_service_work_done >>
- job 1
- job 2
- command or job that notifies individual that external service work has started (e.g., through Slack)
cond: << pipeline.parameters.external_service_work_done >>
- command or job that notifies we are resuming this pipeline since external service work has completed (e.g., through Slack)
- job 3
- job 4
these are some helpful documents on conditional workflows and triggering a workflow via API v2 that are relevant to the scenario:
Note: Should the external service not succeed due to an error then this could cause the workflow to continuously wait for a status update. Please ensure that a recovery method is in place should this situation occur and exit the respective workflow.
This will depend on context:
- If the situation is about indicating to CircleCI (workflow 2) specifically, then one can set up a pipeline parameter to indicate whether the remote work status is good. In this way, workflow 2 will know if the remote service either succeeded or failed.
- If the approach is about notifying one's teams, then using our Slack orb to send notifications can be a viable strategy as well.