Roadmap: none of this exists yet

Versions 0.2 to 0.6, then a list with no order and ideas with no version. The details change as each item is designed.

A CI foundation for checks, five languages and a theme setting

Planned

Code scanning needs the platform to understand checks: results that belong to a commit, show up on a merge request and can stop a merge. This version builds that, translates the interface and lets people choose its theme.

  • Protected branches: no direct push, merge only through a merge request, required approvals and required checks.
  • Pipelines on merge requests, with their status shown on the merge request and required before a merge.
  • Predefined CI variables (commit, branch, merge request, pipeline) and rules to decide when a job runs.
  • Pipeline artifacts and a report upload API, which is what the scans of the next versions use.
  • Re-running a pipeline from the interface, and scheduled pipelines.
  • Personal access tokens usable on the REST API, with scopes, and an OpenAPI description generated from the code.
  • A first link with ArtiFerris: publish an artifact built by a pipeline to an ArtiFerris instance.
  • The interface in English, French, Italian, Spanish and German. The language follows the browser on a first visit, can be changed on the fly and is saved on the account. The e-mails FerrisGit sends use the recipient's language, and the public pages follow the reader's Accept-Language. The documentation is translated afterwards.
  • Dark mode as a setting: choose system, light or dark, saved on the account and applied without a flash. The interface follows the system preference today and has no switch. The logo of the signed-in shell follows the theme too.

The analysis engine, secrets and dependencies

Planned

FerrisGit gets its own analysis engine instead of wrapping third-party tools: a ferrisgit-scan binary that a pipeline job runs, so the analysis scales with the runners and the server stays light. Its analysers are plugins that produce findings in a model close to SARIF, so reports from other tools can still be imported next to the native ones.

  • The engine and the findings store: a scan per commit, findings identified by a stable fingerprint, and a baseline per branch to tell the new findings of a merge request from the old ones.
  • Native secret detection, in the diff of a merge request and in the whole history.
  • Native dependency audit: lockfiles (Cargo.lock, package-lock.json, and others later) matched against public advisory databases such as OSV.
  • Findings shown inline on the merge request diff and summarised in its timeline.
  • Import of SARIF reports from other tools.

Quality gates and the dashboard

Planned
  • Quality gates, configurable per repository: for example no new blocker finding and a minimum coverage on new code. A gate is a required check, so it can block a merge.
  • A repository dashboard: open findings, their age, trend per branch, technical debt and hotspots.
  • Triage: mark a finding as a false positive or as won't fix, assign it, suppress it in the code, and keep the history.
  • A .ferrisgit/scan.yml file to choose analysers, rule sets and thresholds, and to exclude paths.

Code quality

Planned

The full repository is analysed on every push to the default branch and on every merge request, and the gates only look at what a merge request introduces (the "clean as you code" approach), so an existing project stays adoptable.

  • Parsing through tree-sitter, so the same engine reads several languages. Rust and TypeScript first.
  • Metrics: size, cyclomatic and cognitive complexity, duplication.
  • Code smells and bug patterns, as declarative rules and as native rules.
  • Test coverage tracking (LCOV and Cobertura reports), with the coverage of what a merge request changes.

Security analysis and ArtiFerris

Planned
  • Static application security testing: pattern rules first, then data flow within a function.
  • Container image and infrastructure-as-code scanning.
  • A security summary on every merge request and a security dashboard for the repository, with severities and the option to block merging above a chosen severity.
  • Trace every artifact published to ArtiFerris back to the commit, merge request and pipeline that produced it, and show it on the FerrisGit release and pipeline pages.
  • Bring the artifact scan results of ArtiFerris back into the merge request checks.
  • Explore shared identity, so that one account and one MFA enrolment work on both platforms.

The platform, in no fixed order

Planned
  • Git over SSH and deploy keys.
  • Forks and merge requests between repositories; renaming and transferring a repository with redirects.
  • Squash and rebase merges, reopening a merge request, draft merge requests and CODEOWNERS.
  • Mentions (@name), issue references (#12) and closing an issue from a commit or a merge request.
  • Full-text search in the code, and import from GitHub and GitLab.
  • Self-service password reset, e-mail notifications with per-user settings, and single sign-on (OIDC, LDAP).
  • An audit log page in the administration, Prometheus metrics, and backup and restore tooling.
  • Webhooks with retries, a delivery log and more events (push, release).

Under consideration, not scheduled

Under consideration

Ideas with no version yet; what they contain is still to be defined.

  • AI agents on a repository. Candidates: a review assistant on merge requests, summaries of merge requests and commits, an explanation of why a pipeline failed, issue triage and labelling. Whatever ships has to fit a self-hosted platform: a model endpoint the administrator chooses (a local one included), opt-in per repository, scoped credentials, and every action recorded.
  • A commit graph in the repository view: branches, merges and tags drawn together, next to the file tree and the commit list that already exist.
  • Profile photos, stored in S3-compatible object storage. The initials stay as the fallback, and the same storage could later hold release files and pipeline artifacts.

Connecting with ArtiFerris

ArtiFerris already stores npm packages and Docker/OCI images and scans them for vulnerabilities. FerrisGit and ArtiFerris are complementary halves of the same delivery chain. The link grows in three steps: publishing from a pipeline (0.2), tracing an artifact back to its commit (0.6), and bringing the scan results back into the merge request checks (0.6). Shared identity stays an open question.

ArtiFerris on GitHub