SP-2712: expose the LIVE package pointer as config pointer

[Albnor (albnorleku)]

Why

A content-cli release of a Context Model branch had no final step. The branch could be cut with config branch create and checked with config package validate, but selecting it as LIVE — the act that redirects the package's consumers to that branch — was only possible through the Studio UI. Any CLI-driven or agent-driven release therefore stopped one step short of finishing.

Pacman has exposed the pointer publicly at /api/core/pointers/packages/{packageKey} for a while; nothing in content-cli referenced it.

Problem context: SP-2712. Parent epic: SP-1989.

What changed

A beta config pointer group with two commands:

content-cli config pointer set --packageKey <main> --branchKey release-branch
content-cli config pointer get --packageKey <main>

File	Role
pointer/api/pointer.api.ts	Wraps the PUT/GET pointer routes, mirroring the branch module
pointer/interfaces/pointer.interfaces.ts	PackagePointerTransport, SetPackagePointerTransport, and the conflict-body shape
pointer/pointer.command.service.ts	Composes the branched key, maps each status to an actionable message
module.ts	Registers the group as beta
core/http/http-client.ts	Adds putStatusAndData, so a 204 is distinguishable from a body

Four decisions worth flagging for review:

set takes the two keys separately and composes <main>@<branch> itself. Callers never hand-assemble the branched form, and a branched key passed as --packageKey is rejected before a request goes out. main cannot be selected, since returning consumers to the main package is a merge, not a selection.

A 409 carrying package-pointer-blocking-problems is terminal. The message says the branch's problems must be resolved and names config package validate as the way to list them. There is deliberately no override flag — this matches the frontend dropping "Set live anyway" in celonis/ems-frontend#66094.

There is no --validate flag. Pacman's OpenAPI spec declares a validate query parameter on the PUT, but PublicPackagePointerController.set never binds it, so Spring silently discards it. A flag wired to it would report a successful dry run while having performed a real release. I removed the flag rather than ship that. The spec discrepancy is worth fixing separately on the Pacman side.

get distinguishes "no selection" from an error. Pacman answers 204 when the pointer is unset, which is the normal default — consumers read the main package — not a failure.

DELETE is intentionally not wrapped. Moving the selection forward to a corrected branch is a release; clearing it leaves consumers pointed at nothing.

A 403 is reported as ambiguous by design: the route answers 403 both for missing permission and for an inactive pacman.live-branch-pointer feature, with nothing in the body separating them. Claiming one cause would send users to request access they already have.

Testing

yarn test — 621 tests across 71 suites pass, no regressions. New coverage:

• tests/commands/configuration-management/pointer/pointer-set.spec.ts — key composition, the main rejection, the 409 and 403 messages, and an explicit assertion that validate never appears on the request
• tests/commands/configuration-management/pointer/pointer-get.spec.ts — the selected case and the 204 empty case
• tests/integration/commands/configuration-management.spec.ts — command wiring

Two pre-existing tslint no-shadowed-variable errors in logger.ts and http-client.ts come from a tslint/TypeScript version mismatch on DeprecationError and are unrelated to this change.

Docs

docs/user-guide/branch-commands.md gains a LIVE-selection section that states there is no dry run and points at config package validate instead.

Made with Cursor

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud