Files
parsedmarc/CONTRIBUTING.md
T
Sean Whalen a6778707d7 Finish forensic→failure rename: archive-folder migration + dashboard/doc cleanup (#776)
The forensic→failure rename (#659) left a few loose ends and one deliberate
hold-back. This closes them.

Leftover rename misses (broken paths / stale canonical names):
- CONTRIBUTING.md, dashboard-dev-bootstrap.sh: samples/forensic/* → samples/failure/*
- dashboard-dev-bootstrap.sh, dashboards/README.md: dmarc_forensic_dashboard.xml
  → dmarc_failure_dashboard.xml (the file was already renamed; the import path
  and view name were not)
- docs/source/usage.md: PARSEDMARC_GENERAL_SAVE_FORENSIC → ..._SAVE_FAILURE example
- samples/parsedmarc.ini: save_forensic → save_failure
- pyproject.toml, README.md: canonical "failure" naming
(ci.ini intentionally keeps save_forensic to smoke-test the deprecated alias.)

Archive subfolder rename + on-startup migration:
- New failure reports now archive to <archive>/Failure (was <archive>/Forensic).
- _migrate_forensic_archive_folder() runs once on startup (best-effort):
  renames Forensic→Failure when no Failure folder exists yet, merges the two
  when both exist, no-ops when there's no legacy folder, and logs-and-skips a
  mailbox it can't reorganize (warn, don't crash). This consolidates pre- and
  post-rename failure reports into one folder, replacing the previously
  documented decision to keep the folder named Forensic to avoid a split
  archive. Uses the folder-management API (folder_exists / rename_folder /
  merge_folders) added in mailsuite 2.1.0; the pin is bumped to >=2.1.0.

Grafana dashboard (the rename PR updated OSD/Splunk/ES-OS but not Grafana):
- Forensic panel titles + the datasource label → Failure; the fo-column display
  label and its linked byName field-override matcher both → "Failure Policy"
  (changed together so the column-width override keeps matching).
- dev-bootstrap Grafana ES datasource: dmarc_forensic* → dmarc_f* (matches both
  pre-rename dmarc_forensic* and post-rename dmarc_failure*, like the OSD/Kibana
  dashboards); RESEED wipe loop now also clears dmarc_failure* indices.
- Removed dashboards/grafana/Grafana-DMARC_Reports.json-new_panel.json, an
  orphan export accidentally committed in #736 and referenced by nothing.

Tests (tests/test_init.py):
- TestMigrateForensicArchiveFolderMaildir: real on-disk Maildir round-trips via
  mailsuite's MaildirConnection (no mocks) — rename, merge, no-op, and the full
  get_dmarc_reports_from_mailbox orchestration. Runs in CI (no network/creds).
- TestMigrateForensicArchiveFolderErrorHandling: the one path a real Maildir
  can't reproduce — a backend that raises mid-operation must warn, not crash.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-21 12:29:40 -04:00

1.8 KiB

Contributing

Thanks for contributing to parsedmarc.

Local setup

Use a virtual environment for local development.

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
pip install .[build]

Before opening a pull request

Run the checks that match your change:

ruff check .
pytest --cov --cov-report=xml tests.py

If you changed documentation:

cd docs
make html

If you changed CLI behavior or parsing logic, it is also useful to exercise the sample reports:

parsedmarc --debug -c ci.ini samples/aggregate/*
parsedmarc --debug -c ci.ini samples/failure/*

To skip DNS lookups during tests, set:

GITHUB_ACTIONS=true

Pull request guidelines

  • Keep pull requests small and focused. Separate bug fixes, docs updates, and repo-maintenance changes where practical.
  • Add or update tests when behavior changes.
  • Update docs when configuration or user-facing behavior changes.
  • Include a short summary, the reason for the change, and the testing you ran.
  • Link the related issue when there is one.

Branch maintenance

Upstream master may move quickly. Before asking for review or after another PR lands, rebase your branch onto the current upstream branch and force-push with lease if needed:

git fetch upstream
git rebase upstream/master
git push --force-with-lease

CI and coverage

GitHub Actions is the source of truth for linting, docs, and test status.

Codecov patch coverage is usually the most relevant signal for small PRs. Project coverage can be noisier when the base comparison is stale, so interpret it in the context of the actual diff.

Questions

Use GitHub issues for bugs and feature requests. If you are not sure whether a change is wanted, opening an issue first is usually the safest path.