Investigate a policy check failure

In the web app's sidebar, select Policy Checks under Monitor. Each row is one checks run operation. The Severity column shows the violations as counts per severity, from Info through Minor, Major, Critical, and Blocker, before you open anything. Use the Filter operations search bar and the Status dropdown to narrow the list.

Select the operation to open its detail page. The Outcome Breakdown card gives the totals, such as how many checks were evaluated and how many violations they raised. The Findings section is the detail, organized into tabs:

• By Severity: Every violation, worst first. Each row names the check that fired, its description, its severity, and the exact target, either a changeset shown as filepath :: changesetId :: author or a database object, with the source location as file:line.

• By Check: One row per rule, with its scope (Changelog or Database) and how many changesets and objects it flagged. Expand a row to see each flagged item.

• By Changeset and By Database: The same findings grouped by target, so you can see everything one changeset or one database tripped.

Before editing anything, know what the rule is for. A deleteWithoutWhere hit protects data. A naming-convention hit protects operability. The severity the check carries maps to an exit code, which is what actually stopped the pipeline. Each check's behavior and parameters are documented in the policy check reference.

Fix the changeset: This is the usual path. The finding points at the exact pattern. Correct it and rerun the checks locally before pushing back through the pipeline.

Be sure to:

• Replace your_changelog.xml with the changelog the failed run evaluated

Fix the rule: If the check fires on things your organization considers acceptable, that is a governance decision, not a developer workaround. Adjust the check's parameters or severity, or scope it with checks targeting so it skips the changesets it should not judge. Policy changes belong to whoever owns governance.

Note: Liquibase Secure 6.0 has no exemption mechanism. There is no way to waive a check for one change while leaving it enforced. If a rule should not apply, the options are the two above.

Rerun the checks, confirm the pipeline passes, and confirm the new operation appears in Policy Checks with the outcome you expect. The failed run stays in the record as evidence the control worked.