firmware/.coderabbit.yaml at develop · meshtastic/firmware · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
# CodeRabbit config - see https://docs.coderabbit.ai/getting-started/yaml-configuration
language: en-US

reviews:
  # chill = fewer nitpicks.
  profile: chill
  high_level_summary: true
  poem: false
  auto_review:
    enabled: true
    # Don't burn reviews on WIP. This repo opens lots of draft PRs; review on "ready".
    drafts: false
    # Review PRs regardless of target branch.
    base_branches:
      - .*
    # Skip Renovate dependency updates - CI gates dependencies; we review for substance, not every bump.
    ignore_usernames:
      - renovate
      - renovate[bot]
  # Stop reviewing once a PR is closed.
  abort_on_close: true

  path_filters:
    # Generated - don't review, just noise + token burn.
    - "!src/mesh/generated/**"
    - "!protobufs/**"

  path_instructions:
    - path: bin/config.d/**
      instructions: >
        meshtasticd configuration files. Bundled with meshtasticd Linux/MacOS packaging.
        Ensure configurations include metadata found in other configs.
    - path: test/**
      instructions: >
        Native C++ unit tests. The camelCase convention used in src/ does NOT apply here,
        and this is deliberate, not drift. Two separate rules. Suite directories are
        strictly test_[a-z0-9_]+, lowercase only. Test functions take a test_ prefix
        followed by underscore-separated segments, and the case WITHIN a segment is free:
        test_5byte_sequence_rejected and test_getRegion_returnsCorrectRegion_US are both
        correct and both common. Only two things are forbidden for a test function -
        dropping the test_ prefix, and collapsing the segments into a single camelCase
        identifier. Rationale: bin/run-tests.sh matches suite verdict lines against
        test_[a-z0-9_]+, so an uppercase suite directory is reported as missing and
        downgrades the run to AMBER; RUN_TEST in test/TestUtil.h passes #func to Unity, so
        the function name is the only attribution a CI failure carries. Do NOT raise
        naming-convention comments on suite directories or test_* functions, and do NOT
        flag a camelCase segment inside an otherwise underscore-separated test name.
        Helpers and fixtures inside a suite do follow the normal src/ conventions.
        Authoritative rule, which this entry mirrors: the "Test naming" section of
        .github/copilot-instructions.md.

        Comment length is a second deliberate exception. The one-or-two-line comment limit
        does NOT apply to a test's header comment. The header states what is under test by
        symbol and file, why that behavior is required, and the regression that returns if
        the assertions are deleted or relaxed; that routinely runs past two lines and is
        correct at whatever length it needs. Do NOT ask for a test header to be shortened,
        condensed, or moved to the commit message, and do NOT flag it as a multi-paragraph
        block comment. Still DO flag narrative that carries no contract - debugging journey,
        changelog prose, restating what the assertions do - and per-case comments that
        merely repeat the test name. Authoritative rule, which this entry mirrors: the
        "Test comments" section of .github/copilot-instructions.md.
    - path: "**/*.md"
      instructions: >
        Documentation does not live in this repo; it lives in
        https://github.com/meshtastic/meshtastic. Flag any NEW .md file that documents a
        feature, configuration surface, API, wire format, or design, and ask for it to be
        opened against the docs repo instead. Flag any attempt to recreate a docs/
        directory: it was deleted in #11488 and must not come back. Flag write-ups left in
        the tree - investigation notes, mitigation plans, migration checklists, "how we got
        here" narrative, summaries of what a change did - that content belongs in the PR
        description and commit message. Documentation that does belong upstream must read
        as a technical manual, not a novel: what it does, the settings in user terms, the
        API or protocol a client speaks. No debugging journey, no rationale essays, no
        changelog prose.