This page is an overview of what we intend to work on.
- Discuss or propose items in the roadmap: Github: Plumber Roadmap
- Broader issue tracker: GitHub issues.
- Each section describes what we want to deliver and why it matters to users, not how we plan to build it.
- Legend:
- Maturity: 🌱 early · 🌿 growing · 🌳 mature
- Current focus: 🎯
🎯 🌿 Controls and pipeline coverage
Feedback & bug fixes
We keep expanding what Plumber can enforce and what slice of reality it analyzes:
- Merge request approval rules (minimum approvers, code-owner expectations, self-approval, reset on push), aligned with how GitLab exposes them (issue #85).
- Finer-grained CI behavior: letting teams decide which controls fail the run versus report only, so rollouts stay practical (issue #129).
- Triggered and multi-project pipelines: today some graphs are only partly visible; we want explicit handling and clear signaling when a branch of the pipeline cannot be followed (issue #130).
- Ecosystem-aware checks where it pays off, such as deeper awareness of popular CI component catalogs (issue #115).
- More controls overall: we draw ideas from open-source and industry tooling (workflow scanners, supply-chain-focused linters, OSSF baselines) to prioritize controls that matter in real incidents, not only on paper.
🌿 User experience
Clearer errors when something goes wrong: what failed, why, and what to do next (issue #24).
Defaults that stay relevant: our shipped configuration already enables most controls with sensible lists; we continue to map that posture to widely recognized standards (such as OpenSSF Scorecard-style expectations) and document honest gaps.
Faster runs on large projects by only collecting what enabled controls need, with measurable before-and-after checks (issue #77).
🌿 Scoring: clarity and fairness