Skip to content
gapline
GitHub

Severities

Every validation rule ships with a fixed severity. The severity decides whether a finding is a compliance failure, a quality concern, or a best-practice suggestion — and, in CI, whether the pipeline goes red.

The three levels

Section titled “The three levels”

ERROR

Section titled “ERROR”

Your feed is not compliant with the GTFS Schedule spec. A downstream consumer (Google Maps, Apple Maps, a trip planner) will likely reject the feed or silently drop the offending rows.

Examples:

  • A stop_times row references a stop_id that does not exist in stops.txt.
  • A required column is missing from a required file.
  • A route_type value is outside the documented enumeration.

Any ERROR-level finding in a validate run causes the process to exit with code 1 (COMMAND_FAILED).

WARNING

Section titled “WARNING”

The feed is technically compliant, but something about the data is suspicious. Consumers will accept it, but it is likely to produce wrong behavior downstream.

Examples:

  • A calendar_dates.txt service_id with no matching row in calendar.txt (allowed by the spec; still usually a mistake).
  • Two routes share the same route_short_name within one agency.
  • A trip’s shape point is hundreds of meters off the nearest stop.

Warnings do not fail validation by default.

INFO

Section titled “INFO”

A best-practice suggestion. The feed is compliant and internally consistent; the finding is cosmetic or stylistic.

Examples:

  • route_short_name missing on a route that only has route_long_name.
  • Unknown columns (extension fields not defined by the spec) — unknown_column.
  • Unused entities (e.g. a shape not referenced by any trip).

Infos never fail validation and never affect the exit code unless explicitly promoted via --min-severity.

Promotion with --min-severity

Section titled “Promotion with --min-severity”

--min-severity filters and reclassifies. When you pass --min-severity warning, everything below warning is dropped from both the listing and the summary counts. This has two practical effects:

  1. The output is easier to scan — only actionable findings appear.
  2. The PASS/FAIL status flips when previously-filtered warnings become the most severe remaining findings.

In practice:

Terminal window
# Default: only ERROR fails.
gapline validate -f gtfs.zip


# Strict: WARNING now fails too.
gapline validate -f gtfs.zip --min-severity warning


# Stricter still: even INFO findings count.
gapline validate -f gtfs.zip --min-severity info

Use --min-severity warning in CI when you want the pipeline to go red on anything that looks wrong, not just on spec violations.

Disabling a rule entirely

Section titled “Disabling a rule entirely”

Sometimes a rule is too strict for your feed — for example, an internal route that intentionally overlaps a block with another trip. Disable it with --disable-rule <RULE_ID>:

Terminal window
gapline validate -f gtfs.zip --disable-rule block_id_trip_overlap

Find every rule ID with gapline rules list. Shell completion suggests IDs dynamically.

You can pin a permanent list in gapline.toml:

gapline.toml
[validation]
disabled_rules = ["block_id_trip_overlap", "duplicate_coordinates"]

--disable-rule on the command line appends to the config list — it does not replace it.

Common patterns

Section titled “Common patterns”
GoalFlag
Only fail the build on ERROR-level findings (default).(none)
Also fail on WARNING.--min-severity warning
Fail on anything found.--min-severity info
Keep the default policy but silence one specific rule.--disable-rule <RULE_ID>
Silence a rule for this run only, on top of the config’s disabled list.--disable-rule <RULE_ID> (appended)

See also

Section titled “See also”