Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Add --allow CODE to exclude specific problem codes from validate's pass/fail decision

Đã đóng
  • Có gì không ổn?
#2 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

@imnasnainaec đang làm issue này rồi.

Từ ngày 24/9/2026.

  • #48 của @imnasnainaec — đã merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
cli

Hướng nghiên cứu

Bắt đầu tại src/sil_lift/_cli.py, ở _cmd_validate, và lần theo quá trình phân tích đối số của validate, việc đếm vấn đề, quyết định thoát strict và đầu ra tóm tắt JSON. Đọc docs/en/guides/validate.md và docs/en/guides/lift-export-interop.md để biết hành vi và interface được tài liệu hóa; công việc được hoàn tất khi việc lặp lại --allow CODE vẫn giữ nguyên các findings được phát ra, đồng thời loại các mã khớp khỏi các bộ đếm quyết định, và đã xử lý số lượng additive của các mục được cho phép trong phần tóm tắt cùng các quyết định open-policy được tài liệu hóa.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Problem

sil-lift validate --strict is meant as a CI conformance gate (see the interop guide), but real-world FieldWorks/FLEx exports trip several warning-level findings that are expected FLEx quirks rather than defects — uri-not-rfc being the clearest example (documented policy in docs/en/guides/validate.md). Right now the only lever is --no-check-media, which is hardcoded to one specific code (missing-media) and fully suppresses it from output rather than just excluding it from the strict decision.

A caller who wants --strict for genuine regressions but doesn't want it to fail on a known-tolerated code (e.g. uri-not-rfc) currently has no way to express that short of post-processing --format json output themselves.

Proposed solution

Add a repeatable --allow CODE flag to validate:

sil-lift validate export.lift --strict --allow uri-not-rfc

Semantics: problems whose code is in the allow-list are still collected and printed/emitted (so a human or a CI log still sees them), but they're excluded from the errors/warnings counts that decide the exit code and from --strict escalation. This differs from --no-check-media, which drops missing-media findings entirely.

Sketch of the affected logic in _cmd_validate (src/sil_lift/_cli.py):

def _cmd_validate(args: argparse.Namespace) -> int:
    problems = _collect_problems(args)
    allowed = set(args.allow)
    counted = [p for p in problems if p.code not in allowed]
    errors = sum(1 for p in counted if p.level == "error")
    warnings = len(counted) - errors
    failed = bool(errors) or (args.strict and bool(warnings))
    ...

For --format json, add an additive summary.allowed count alongside the existing errors/warnings.

Open questions

  • Scope: should --allow apply to error-level codes too (e.g. the trait/field-in-range-element schema errors that are deliberately kept as errors per policy), or warnings only? The mechanism above is symmetric either way — it's a decision about what we want to invite people to silence.
  • Unknown codes: should --allow on a code that never appears (typo, or a code that doesn't exist) warn/error, or silently no-op? Leaning toward silent no-op for forward-compatibility (a code retired in a later version shouldn't break an existing --allow list).

Alternatives considered

  • A dedicated --flex flag that downgrades a fixed, tool-chosen set of "FLEx-known" warnings to an info level. Rejected: uri-not-rfc is the only warning that's genuinely FLEx-specific under current policy (missing-media, undefined-range-value are generic, source-agnostic data problems a gate might legitimately want to fail on), and introducing a third Problem.level value widens the documented/SemVer-covered JSON schema for one code's benefit. --allow CODE covers the same need generally, without the tool prescribing what counts as "FLEx-known."
Ngôn ngữ chính
Python
Star
1
Fork
0
Merge trung bình
11 ngày 8 giờ
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sillsdev/python-sil-lift

Tất cả issue của sillsdev/python-sil-lift

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.