[Feature]: CICD Flow for AI-Workspace

[ShakyaPr]

Please select the area the issue is related to

Area/Other - CICD

Please select the aspect the issue is related to

Aspect/Other (Anything else which does not match above categories)

Suggested Feature

Need to define a standard CI/CD flow for the API Platform so that all future components can follow a consistent approach when supporting CI/CD-based artifact management.

As the initial implementation, this flow should be introduced for the integration between AI Workspace and Platform Gateway. This should allow LLM-related artifacts to be created, deployed, updated, and managed through a CI/CD workflow.

This should cover the following:

• Define the standard CI/CD flow for API Platform components.
• Implement the CI/CD flow between AI Workspace and Platform Gateway.
• Do the required additional changes in Platform API or AI Gateway

Related Issues

No response

[ShakyaPr]

Update 11/06/2026

• Initiated a Discussion: [Discussion] CICD Flow for AI-Workspace #2154

[ShakyaPr]

Update 26/06/2026

• Implemented the CLI commands required for the AI Workspace CI/CD flow, including create, update, list, get, and delete operations for LLM providers, LLM proxies, and MCP proxies.
• Enhanced the API Project structure to support the AI Workspace CI/CD workflow.
• Had several discussions on how associated gateways should be represented and managed for AI Workspace artifacts, and finalized the approach following multiple internal offline discussions.
• Raised a PR for AI-workspace related db schema & API spec changes : Update db schema & api spec for cicd feature #2264
• Design doc was created - https://docs.google.com/document/d/1DWklILdlBFAijachx2M3zz1iD8D7qlY3tuxEDyo7io8/edit?tab=t.w3lefdjelsk5#heading=h.qxwb86l2rlwz

[ShakyaPr]

Update 01/07/2026

• When updating gateway associations for an artifact during the UPDATE operation, there is a possible race condition if an update operation and a deploy operation happen on the same artifact at the same time.
• Consider the following scenario:

D: begin tx 
D: read association (X,G) -> found 
U: begin tx 
U: guardLiveGatewaysRetainedTx -> SELECT deployment_status WHERE status is live
           -> G is NOT live because D has not committed its status yet 
           -> guard PASSES 
U: replaceArtifactGatewayAssociations -> deletes all existing mappings and inserts the requested set without G 
D: no insert association (X,G), since the association was already found earlier 
D: insert deployment 
D: upsert status = DEPLOYED 
D: commit 
U: commit

• This scenario could eventually result in stale data in the database. However, this can only happen if the CI/CD flow is defined incorrectly.
• In the artifact UPDATE operation, if a previous gateway association is no longer present in the request, it means the artifact is no longer expected to be available in that gateway. Therefore, the user should apply the corresponding change to the gateway as well, so that the artifact is removed from the gateway.
• Once the artifact is removed from the gateway, the gateway will emit a delete event. Based on that event, the Control Plane will remove the relevant deployment records from the Control Plane database. As a result, the system will eventually become consistent.
• This was discussed and concluded during the offline discussion with @dushaniw
• Therefore, this race condition will not be handled separately. In the artifact UPDATE operation, we will simply remove the gateway association mappings that are no longer present in the request, as long as they are not blocked by the live deployment guard.

Final PR : #2340