nordisk/holger

Contributing to Holger

Thank you for your interest in Holger. This page says how to get the code, how to report a bug, and how to propose a change.

Get the code

Anyone can clone the repository anonymously over SSH. Any SSH key works, and it does not have to be registered:

git clone ssh://anonymous@git.gunnar.rs:2222/nordisk/holger.git
cd holger
cargo build --release

The main branch is main. The released crates are on crates.io (cargo install holger).

Report a bug or ask for a feature

Issues live on gunnar.rs, in the repository nordisk/holger. Public reading of the issues is coming. Until then you need an account on https://www.gunnar.rs to file or read an issue: sign up there with a passkey, then open the issue in the console. With the Gunnar CLI, gunnar forge issue open --repo nordisk/holger --title … --body … files a signed issue.

If you cannot sign up, write to holger@holger.rs.

A good bug report gives:

• the version (holger --version) or the commit, and the build features;
• the part of holger.ron that matters, with secrets left out;
• what you did, what you expected, and what happened instead;
• the log lines or the error code Holger printed (for example holger-intake-14).

Do not report a vulnerability as an issue. Follow SECURITY.md instead.

Propose a change

1. Start from a fresh main, on a branch of your own.
2. Make the change in small commits. Each commit message says what changed and why.
3. Push the branch to a repository of your own on gunnar.rs and open a pull request against main in the console. Contributions come only as pull requests on git.gunnar.rs; patches by e-mail are not taken.
4. A maintainer reviews the change. It is merged with git merge --no-ff when the review and the checks below are green.

Before your first change is merged, you accept the Contributor License Agreement in CLA.md: your first pull request adds one line to CLA-SIGNATURES.md (see below).

Coding rules

• Format the code you change with rustfmt. The settings are in rustfmt.toml, which is the same in every repository of the project. Do not run cargo fmt --all: it reaches into the sibling repositories through the path dependencies. Format the files you change.
• Clippy is clean: cargo clippy --workspace --all-targets -- -D warnings. cargo xtask ci does not run clippy yet, so run it yourself.
• cargo xtask ci is green. It runs the lock check, the lone-clone build, the test suites and the end-to-end gates. Some steps need the sibling repositories beside the clone or a container engine; the step says so by name when one is missing. From a lone clone, git lfs pull and then cargo test --workspace --locked run the open core's tests.
• Every change comes with a test. A bug fix starts with a failing test. Commit the failing test first (its message starts with RED), then the fix that makes it pass (GREEN). The reviewer runs the test at both commits.
• A new dependency needs a reason in the commit message, and it must pass cargo deny --locked check (licences, sources and advisories, see deny.toml).
• Commit messages carry no AI co-author trailers. The forge refuses them.

Dependency updates

renovate.json is the update policy: semver-compatible cargo updates grouped, the locks refreshed weekly, a major version only after a person approves it, and an update that closes an advisory at once. No Renovate bot runs on git.gunnar.rs. The dwarves forge's deps-update job is what proposes the updates: it runs cargo update on every committed lock, pushes the result as a branch, and the forge's CI runs the gate on that branch; a person merges it. An advisory that has no fix is triaged in deny.toml (the cargo-deny gate) and in the osv-scanner.toml beside each lock (what OpenSSF Scorecard reads), with a dated reason; xtask/tests/ossf_scorecard.rs keeps the two equal.

Licence of contributions

Holger is dual licensed: under the GNU Affero General Public License v3.0 only (AGPL-3.0-only), and under a commercial licence (see COMMERCIAL-LICENSING.md). It is owned jointly by Ignalina ApS and Vetra Automation AB. A few crates are MIT OR Apache-2.0; their Cargo.toml says so.

Because of the dual licence, every outside contribution needs the Contributor License Agreement (CLA) in CLA.md, version 1.1. It grants Ignalina ApS and Vetra Automation AB a licence to your contribution, including the right to license it under the commercial licence as well as under the AGPL, and a licence to any patent of yours that the contribution necessarily uses. You confirm that the contribution is yours to give. You keep the copyright in your contribution.

To accept the CLA, add one line to CLA-SIGNATURES.md in your first pull request:

- Jane Doe, forge account jdoe, 2026-11-02: I agree to CLA.md version 1.1

This line is the only way to accept the CLA. You accept once; it covers all your contributions. Questions about the CLA: holger@holger.rs.

Conduct

Be kind and stay on the subject. Criticise code, not people. The full code of conduct is CODE_OF_CONDUCT.md (the Contributor Covenant 2.1); who decides what is in GOVERNANCE.md, and how a release is made is in RELEASING.md.