Triggers
There are 3 ways to trigger a NetOrca Pack Pipeline:
- Automatically via Change Instance Approval.
- Trigger an AI Processor via endpoint directly.
- Push a PackData for each stage manually via API.
When each stage is finished successfully, the next stage will be triggered automatically if there exists an active AI processor for the next stage.
1. Automatically via Change Instance Approval
When a Config AI Processor is set up for a Service, the approval of any Change Instance related to that Service will automatically start the CONFIG stage. If auto-approval is enabled for a Service, the Change Instance will be approved immediately upon consumer submission, which will also trigger the Config AI Processor. With this option, the infrastructure configuration for the Service Item will be created or updated immediately after consumer submission, ensuring the fastest possible processing with no delay.
2. Trigger an AI Processor via endpoint directly.
Service Owners can trigger an active AI Processor directly via an endpoint. This will take the latest approved declaration of the Service Item and initiate the pipeline. Each stage can be triggered separately, provided the PackData from the previous stage exists. To do so:
Retrigger
The Retrigger endpoint restarts the entire pipeline from the CONFIG stage while preserving the previous execution context. This is useful when troubleshooting failed executions. A Service Owner can also provide a feedback comment, which becomes part of the execution context to help the self-healing mechanism correct the config. To retrigger a pipeline:
3. Push a PackData for each stage manually via API.
Each stage of NetOrca Pack Pipeline does not always have to be generated directly by the AI Processor or LLM. Service Owners can provide PackData from external services, scripts, or testing frameworks and insert it into any stage in the pipeline, effectively replacing or augmenting the AI-driven step.
For example, CONFIG and VERIFY Pack Data can be generated by the AI Processor, while an external script can take the both stage data and run tests in a simulation environment. If errors are detected, the script can push the error details back into the RESULTS stage, which may then retrigger the workflow for self-healing. In this retriggered cycle, the CONFIG AI Processor will have the error context available, allowing it to attempt an automatic fix.
To directly push the PackData for each stage, use the following endpoints:
If an AI Processor is available and active for the next stage, it will be triggered, automatically.