Split deployment gates setup into JIT and preconfigured pages#37364
Split deployment gates setup into JIT and preconfigured pages#37364GabrielAnca wants to merge 3 commits into
Conversation
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
|
Preview links (active after the
|
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
/review |
|
Created a DOCS card for an editorial review. |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Nice restructure — the JIT vs preconfigured split is much clearer than a single page trying to cover both. A few specific notes inline: one typo in an example UUID, one style nit, and one minor consistency issue with an unpinned image tag.
Reviewed 110b0359fde269068efc09658f2fa241f326f19f — workflow run
| restartPolicy: Never | ||
| containers: | ||
| - name: datadog-check | ||
| image: datadog/ci:latest |
There was a problem hiding this comment.
Suggestion: The page tells readers to use a datadog-ci version that supports --config (line 202), but this example pins to datadog/ci:latest, which makes it ambiguous which version a reader actually runs. Pin to a specific tag known to support --config so the example stays consistent with the version guidance above.
There was a problem hiding this comment.
There is a todo for this in the PR description. I'll update this as soon as the corresponding datadog-ci version has been released
| | **Where rules live** | Inline in your deployment config or CI step | Persisted in Datadog (UI, API, or Terraform) | | ||
| | **Setup in Datadog** | None | Create a gate and rules ahead of time | | ||
| | **Best for** | Rules-as-code, per-deployment flexibility, teams that own their own gate config | Shared rules across services, central management, non-CI editing | | ||
| | **How to evaluate** | Send rules in the evaluation request | Reference the gate by service and environment | |
There was a problem hiding this comment.
Do we want to mention the identifier here as well?
| "configuration": { | ||
| "dry_run": false, | ||
| "rules": [ | ||
| { "type": "...", "name": "...", "options": { ... } } |
There was a problem hiding this comment.
Shall we make this a full example?
| {{< /tabs >}} | ||
|
|
||
| ## Evaluate Deployment Gates | ||
| ## Evaluate a gate from your pipeline |
There was a problem hiding this comment.
Not from this PR, but we can tackle it now: I'd add identifier: default to the examples here. A lot of customers add identifier to their gates because they don't know what it is, and then cannot evaluate the gate because they miss it when copy-pasting the example
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
What does this PR do? What is the motivation?
Splits Deployment Gates setup into two dedicated pages — JIT and preconfigured — instead of mixing both modes on a single page. Each setup page describes only the workflow for its mode (creation steps, integration tabs, dry-run guidance), and the existing
/deployment_gates/setup/URL becomes a short landing page that helps readers choose between the two modes.The menu adds two children under Setup (JIT and Preconfigured); the existing setup URL is preserved.
This is an alternative to #37327, which keeps both modes on the same page with JIT-first ordering.
Merge instructions
Merge readiness:
Additional notes
TODO before merge — update version numbers once the supporting PRs land:
datadog-ci--configflag: Add config file support to deployment gate command datadog-ci#2339deployment-gate-github-actionconfiginput: Add config input to deployment gate action deployment-gate-github-action#14Once those merge, replace the placeholder version references in
content/en/deployment_gates/setup/jit.md(CLI release-notes link,datadog/ci:latestimage tag in the Argo example,deployment-gate-github-action@v1major-version pin) with concrete versions.