Uipath Aops

UiPath StudioAdmin AOps — Source Control + CICD Pipelines

Depends on the @uipath/aops-tool CLI plugin; install via uip tools install @uipath/aops-tool before using.

Tool migration. @uipath/sc-tool (uip sc) and @uipath/cicd-tool (uip cicd) were unified into @uipath/aops-tool (uip aops). @uipath/cicd-tool is gone from npm. Every uip sc <verb> and uip cicd <verb> becomes uip aops <verb> — the verb trees merged without renaming any subcommand. See migration-guide.md. <!-- uip-check-skip -->

Build a StudioAdmin CICD pipeline that binds two independent things:

• Source — one Studio project the pipeline checks out on every run. Two equivalent ways to reach it:
  • Solution path — a project inside a Studio Solution surfaced by aops connection solutions <connection-id>
  • Standalone-project path — a project surfaced directly by aops connection projects <connection-id> (no enclosing Solution)
• Target — an already-published Orchestrator automation process surfaced by aops pipeline processes. The pipeline runs / updates this process as part of its execution.

When to Use This Skill

• User wants a new pipeline for a Studio Solution or standalone project already synced to StudioAdmin
• User names a published Orchestrator process and wants a pipeline that runs / updates it
• User says "create / build / wire a pipeline" against a Solution or a process
• User wants a one-shot "create and run" with execution id + log follow
• User wants to inspect or kick off an existing pipeline run, or edit one after creation
• User wants to inspect SourceControl state — connections, repos, branches, project files, commit history

Do NOT use this skill for:

• AOps governance policies (uip gov aops-policy — Studio / Robot feature restrictions) → uipath-governance. Same "AOps" word, different product surface.
• Packing or publishing a .nupkg (uip solution pack/publish/deploy) → uipath-platform
• Authoring or editing workflow code (.xaml, .cs) → uipath-rpa
• Creating the SourceControl connection itself — connections are UI-only via the StudioAdmin web app
• Publishing a new process — processes are published separately (Studio publish / uip solution publish)

Vocabulary

The published process is NOT the same thing as a Studio project of type "Process". Studio project types describe how to build / package source. Published processes are runnable artifacts in Orchestrator. The pipeline glues them: build source → update / run the target process.

Critical Rules

1. The tool is aops, not sc / cicd. Run uip tools list --output json and confirm an entry with commandPrefix: "aops". If missing: uip tools install @uipath/aops-tool. If the registry does not know the package, see migration-guide.md § Install. Then uip login status --output json; if not logged in, uip login.
2. Response keys are PascalCase; --file input keys are camelCase. The CLI PascalCases every key inside the stdout Data payload (Identifier, RemoteId, CloneUrl, DefaultBranch, ProjectRelativePath). The JSON you write for --file must use the DTO's own camelCase names (repositoryId, projectPath, processIdentifier). Never round-trip stdout into --file. Use --output-file when you need a raw DTO on disk.
3. Sources come from AOps, not local disk. Do NOT scan *.sln / *.uipx / project.json files. Discover via uip aops connection solutions <connection-id> and uip aops connection projects <connection-id>. Local files don't carry connectionIdentifier / remoteId / project SourceControl UUIDs — fields the CICD API requires.
4. Source project and target process are independent picks. The pipeline binds one Studio project (for source) AND one already-published Orchestrator process (for run / update). Do NOT auto-derive the process from the project's name or type, and do NOT filter projects by Type. Both come from separate API calls; the user (or context) picks each.
5. pipeline create --file consumes a PipelineDto, NOT an EditPipelineDto. The two shapes differ — EditPipelineDto is for pipeline update. See pipeline-dto-guide.md.
6. branch is the only hard-required field on PipelineDto. Everything else is optional in the type system, but a useful pipeline needs name, connectionIdentifier, repositoryId, projectPath, processIdentifier, and runMode. Default branch to the repository's DefaultBranch unless the user specifies one.
7. --output json on every command. All uip aops calls are parsed by the agent. Never run them without it. Do NOT add --output-filter to a command that has a defaulted --limit unless you also pass --limit explicitly — the CLI refuses that combination (Rule 13).
8. The published process is the user's pick. pipeline processes returns {ProcessId, Name, Description, Package, Version}. When the user names a process by Name or Package, find the exact match — if 2+ candidates remain (same Package, different versions), prefer the highest Version and confirm. Never silently bind a process the user didn't name.
9. Process arguments are process-specific — inspect, infer, then ask. Before composing PipelineDto.arguments: (1) run aops pipeline process <PROCESS_ID> --output json to read Arguments (declared schema) + InputArguments (JSON string of default values). (2) Infer overrides from conversation context. (3) Ask the user only for parameters that cannot be inferred AND have no schema default. Default the field to null (= use process defaults). See pipeline-dto-guide.md § arguments.
10. Connection-and-source discovery is two calls, in order. connection list → pick the connection → connection solutions / connection projects. Never assume there is exactly one connection or one solution.
11. If discovery returns nothing, then sync. Try connection solutions <id> / connection projects <id> first. If both return an empty list OR the user reports a missing solution / project that was just added, check connection state --connection <id> and offer connection sync <id> --wait. A SyncState: "Fail" value is not by itself a reason to bail — cached data from the last successful sync is usually still usable.
12. Never invent identifiers. Source map:
    • connectionIdentifier ← connection list → Identifier (SourceControl UUID).
    • repositoryId ← connection repos → RemoteId (provider-native id: numeric for GitHub, UUID for Azure DevOps). NOT Identifier (SourceControl's internal UUID). Sending the SourceControl UUID makes pipeline create succeed but the pipeline fails runtime resolution — the StudioAdmin UI flags it "connection no longer valid".
    • projectPath ← connection solutions → Projects[].ProjectRelativePath, or repo project-files <repo-id> → Path.
    • processIdentifier ← pipeline processes → ProcessId.
13. Pagination is page-based. --offset must be an exact multiple of --limit or the command fails client-side before any request. Defaults: connection projects / project list 10; connection solutions / pipeline list / pipeline executions 20. --take / --skip are deprecated aliases on the connection and project verbs and do not exist at all on pipeline executions.
14. pipeline delete requires -y / --yes. The CLI never prompts. Without the flag the command refuses and no request is sent. Confirm with the user before passing it.
15. pipeline update --file is a full-replace PUT that rejects unknown keys. It accepts exactly identifier, name, runMode, description, arguments. Any other key — including one differing only in case — is a ValidationError (exit 3) and nothing is sent. Produce the file with pipeline get <id> --for-update --output-file <path>, never by capturing stdout.
16. pipeline create returns the persisted PipelineDto. Success is {Result: "Success", Code: "PipelineCreated", Data: {…, "Identifier": "<new-id>"}}. Capture Data.Identifier for follow-up run / update / delete calls.
17. pipeline save-and-run returns Data.Pipeline + Data.ExecutionId. ExecutionId is lifted out of the persisted DTO's latestPipelineExecution; when it is null the run was queued but the response didn't surface the row — fall back to pipeline executions <pipeline-id> --limit 1 --output json. See save-and-run-guide.md.

Quick Start

The end-to-end flow is 7 steps (Step 3 has two variants — 3a for Solution-nested sources, 3b for standalone projects). The full procedure with example output and error handling is in discovery-flow.md. Reach for it whenever a step needs more detail than the snippet below.

Step 0 — Tool + auth check

uip tools list --output json
uip login status --output json

If aops is missing: uip tools install @uipath/aops-tool. If not logged in: uip login. The SourceControl and CICD halves share one token but are separately entitled — SourceControl verbs need the StudioAdmin SourceControl service; pipeline verbs need StudioAdmin CICD plus Pipelines.View (mutations need Pipelines.Edit / Pipelines.Run) on the active runtime environment.

Step 1 — Pick the SourceControl connection

uip aops connection list --output json

Row shape: {Identifier, Name, Type, SyncState}. Type is "GitHub" or "Azure". Save the chosen Identifier as CONNECTION_ID. If multiple connections are returned and the user didn't name one, ask the user.

Step 2 — Pick the source: Solution-nested project OR standalone project

Both kinds of source live on the same connection. List both, then let the user pick from the combined set:

uip aops connection solutions <CONNECTION_ID> --output json
uip aops connection projects <CONNECTION_ID> --output json

• connection solutions returns Data.Result[] (paged, default 20) of SolutionDto. Each row has Identifier, Name, Path, Repository (full RepositoryDto), and Projects[] (each {ProjectId, Type, ProjectRelativePath}).
• connection projects returns Data[] of curated rows {ProjectId, Name, Description, Type, Repository} (paged, default 10). Repository is just the name — the curated view drops the full RepositoryDto and the project file's path. Recover the rest in Step 3b.

Decision:

• User named a Solution → Solution path (Step 3a).
• User named a standalone project that appears only in connection projects → standalone path (Step 3b).
• User named a name appearing in both → ask the user.
• No user hint → list every Solution + every standalone project (label which is which) and ask the user.

Step 3a — Solution path: pick a project inside the Solution

For the chosen Solution, list Projects[]. Common Type values: Process, Library, TestCase. Do not filter by Type — any project can serve as a pipeline's source binding.

• 1 project → use it.
• 2+ projects → ask the user, listing each project's Type and ProjectRelativePath.
• 0 projects → fail with Result: "Failure", instruct the user to add a project to the Solution and re-sync.

The Solution's embedded Repository lacks RemoteId. One extra call:

uip aops connection repos <CONNECTION_ID> --output json

Find the row whose Identifier matches solution.Repository.Identifier. That row carries RemoteId.

Derive the DTO fields:

Skip to Step 4.