Public REST API for per-environment release track
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
Build public REST API for per-environment release track with authn/authz
Parent epic: dotCMS/core#35693 · Workstream B (Self-service) · Post-launch
Background
Customers want to read and change an environment's track from their own CI/CD pipelines. This issue delivers the public REST API sketched in the epic, backed by the persisted data model, with the authentication/authorization model chosen in the surface/auth ADR.
Scope
- Implement:
GET /api/v1/environments/{id}/release-trackPUT /api/v1/environments/{id}/release-track{ "track": "standard" }GET /api/v1/release-tracks(list available tracks)
- Enforce authn/authz per the dotCMS/private-issues#654 decision (which roles/identities can read vs change).
- Enforce forward-only semantics and validate track values; return clear errors.
- Trigger the underlying track change operation (manifest/registry update) on PUT.
- API tests covering authz, validation, and the forward-only rule.
Out of scope
- UI (#36531) and audit/eventing (#36530, consumed via the change path).
- Cadence/version-pin parameters (deferred by the epic).
Acceptance criteria
- All three endpoints implemented and documented.
- Authn/authz enforced per the dotCMS/private-issues#654 ADR.
- PUT applies a real track change and rejects invalid/backward moves appropriately.
- Test coverage for authz, validation, and forward-only behavior.
Depends on
- dotCMS/private-issues#654 (auth model).
- dotCMS/core#36528 (backing store).
Blocks
- dotCMS/core#36531, dotCMS/infrastructure-as-code#7988.
Part of the Evergreen Release Tracks epic. Parent: dotCMS/core#35693.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the three endpoint requirements and the authentication model in dotCMS/private-issues#654, then review the backing-store work in dotCMS/core#36528. Confirm how the manifest or registry change path is invoked and define API tests for authorization, track validation, and forward-only behavior. Done means all endpoints are implemented, documented, secured, and covered by the stated acceptance criteria.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, authorization, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100