Skip to content
Big Picture

Approving a Release

This workflow covers reviewing and approving releases before they are distributed to clients. Approval workflows help ensure quality and compliance before releases reach production.

Prerequisites

Section titled “Prerequisites”
  • API credentials with release approval permissions
  • A release created and pending approval (if approval workflows are enabled)
  • Understanding of your organization’s release approval requirements

Understanding Approval Workflows

Section titled “Understanding Approval Workflows”

Approval workflows are optional and configurable per tenant or product. When enabled:

  • Releases require approval before being distributed
  • Approvers review release metadata and artifacts
  • Approved releases become available to clients
  • Rejected releases remain in the catalog but are not distributed

Step 1: Check Release Status

Section titled “Step 1: Check Release Status”

Query the release to check its approval status:

Terminal window
curl "${BP_BASE_URL}/v1/releases/rel_abc123" \
  -H "Authorization: Bearer $BP_API_TOKEN"

Response includes:

  • status — Release status (pending_approval, approved, rejected)
  • approval_history — List of approval actions
  • metadata — Release notes and compatibility information

Step 2: Review Release Details

Section titled “Step 2: Review Release Details”

Review the release before approving:

Check artifacts:

Terminal window
curl "${BP_BASE_URL}/v1/releases/rel_abc123/artifacts" \
  -H "Authorization: Bearer $BP_API_TOKEN"

Check verification status:

Terminal window
curl "${BP_BASE_URL}/v1/releases/rel_abc123/verification" \
  -H "Authorization: Bearer $BP_API_TOKEN"

Review metadata:

  • Release notes
  • Compatibility requirements
  • Known issues
  • Breaking changes

Step 3: Approve Release

Section titled “Step 3: Approve Release”

Approve the release:

Terminal window
curl -X POST "${BP_BASE_URL}/v1/releases/rel_abc123/approve" \
  -H "Authorization: Bearer $BP_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "approved_by": "admin@example.com",
    "approval_notes": "Reviewed and approved for production release"
  }'

Response:

{
  "release_id": "rel_abc123",
  "status": "approved",
  "approved_at": "2024-01-15T10:30:00Z",
  "approved_by": "admin@example.com"
}

Step 4: Reject Release (If Needed)

Section titled “Step 4: Reject Release (If Needed)”

If the release does not meet requirements, reject it:

Terminal window
curl -X POST "${BP_BASE_URL}/v1/releases/rel_abc123/reject" \
  -H "Authorization: Bearer $BP_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rejected_by": "admin@example.com",
    "rejection_reason": "Security scan failed - requires remediation"
  }'

Response:

{
  "release_id": "rel_abc123",
  "status": "rejected",
  "rejected_at": "2024-01-15T10:30:00Z",
  "rejected_by": "admin@example.com",
  "rejection_reason": "Security scan failed - requires remediation"
}

Rejected releases remain in the catalog but are not distributed to clients.

Approval Requirements

Section titled “Approval Requirements”

Approval requirements depend on your configuration:

Single approver: One approval is sufficient.

Multiple approvers: Multiple approvals may be required (e.g., security team and product team).

Approval expiration: Approvals may expire after a set period, requiring re-approval.

Automatic approval: Releases may be auto-approved under certain conditions (e.g., internal channel, specific products).

Checking Approval History

Section titled “Checking Approval History”

View approval history for a release:

Terminal window
curl "${BP_BASE_URL}/v1/releases/rel_abc123/approval-history" \
  -H "Authorization: Bearer $BP_API_TOKEN"

Response:

{
  "release_id": "rel_abc123",
  "history": [
    {
      "action": "approved",
      "actor": "admin@example.com",
      "timestamp": "2024-01-15T10:30:00Z",
      "notes": "Reviewed and approved for production release"
    }
  ]
}

Best Practices

Section titled “Best Practices”

Review before approval: Always review release metadata, artifacts, and verification status before approving.

Document decisions: Include approval notes explaining why a release was approved or rejected.

Verify artifacts: Ensure artifacts pass verification checks—see Verifying Artifacts.

Test releases: Test releases in staging or beta channels before approving for production.

Audit trail: Approval history provides an audit trail for compliance and troubleshooting.

Next Steps

Section titled “Next Steps”