ATC in a CI/CD pipeline
What you'll learn
On each PR, run abaplint (--format=json) plus remote ATC over the Code Inspector RFC, fail above an agreed severity, and log the ATC run id back on the PR.
- 1. Keep the source in git via abapGit.
- 2. On a pull request, run static lint with abaplint --format=json.
- 3. Run remote ATC via the Code Inspector RFC against the package.
Shifting quality left means catching findings before they ever reach a transport. With the source mirrored to git via abapGit, an external CI runner can react to a pull request and run two complementary checks: a fast static lint that needs no SAP system, and the authoritative remote ATC that does.
The static stage runs abaplint with --format=json so the runner can parse findings programmatically — it catches style and many ATC-equivalent issues offline, in seconds, on the PR branch. The authoritative stage then invokes remote ATC through the Code Inspector RFC against the package, applying the same rule set the central system enforces.
The gate is a policy decision: the pipeline fails when findings exceed an agreed severity threshold, so trivial warnings do not block merges but real violations do. Finally, log the ATC run id back onto the PR, so a reviewer can open the exact run that justified the green (or red) check and the audit trail is intact.
Key points
- 1. Keep the source in git via abapGit.
- 2. On a pull request, run static lint with abaplint --format=json.
- 3. Run remote ATC via the Code Inspector RFC against the package.
- 4. Fail the pipeline when findings exceed the agreed severity threshold.
- 5. Log the ATC run id on the PR for traceability.
Source notes: clean-core-curriculum §12.6
Ask Claude
Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.