dotCMS / dotCMS/core

Public REST API for per-environment release track

Open
#36,529 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

OKR : Evergreen Team : Enablement
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-track
    • PUT /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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.