Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions .github/workflows/compliance.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University
# SPDX-License-Identifier: MPL-2.0

name: Compliance checks

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add SPDX license header to compliance.yaml
severity: high · confidence: 96%

compliance.yaml is a new GitHub Actions workflow file and must include an SPDX license header in the file's own comment syntax. YAML files use # for comments, so the header should be the first line of the file.

Suggested fix: Add the following SPDX header as the first line of compliance.yaml:

SPDX-FileCopyrightText: 2025 Contributors to DPsim

SPDX-License-Identifier: MPL-2.0

Immediately after the shebang line if present, or as the first line otherwise.

Suggested change
name: Compliance checks
# SPDX-FileCopyrightText: 2025 Contributors to DPsim
# SPDX-License-Identifier: MPL-2.0
name: Compliance checks
on:
pull_request:
branches: [master, main]

Checked against the source: new workflow starts with name: Compliance checks and contains no SPDX comment header

stage: process-compliance

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing SPDX license header
severity: high · confidence: 96%

The new workflow file lacks the required SPDX-License-Identifier and copyright header using the appropriate comment syntax for YAML. Absence of SPDX metadata violates the project's licensing compliance process and may cause downstream license scanning failures.

Suggested fix: Add a YAML comment header at the top of the file with the SPDX lines, e.g.:

SPDX-FileCopyrightText: 2025 Leonardo Carreras leonardo.carreras@eonerc.rwth-aachen.de

SPDX-License-Identifier: MPL-2.0

Place these lines before any other content (or after a shebang if present).

Checked against the source: YAML file begins without the required SPDX license/copyright header

stage: process-compliance

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing SPDX header in new workflow file
severity: medium · confidence: 96%

Documentation states that all new files must include an SPDX license header. The newly added GitHub Actions workflow lacks the required SPDX-FileCopyrightText and SPDX-License-Identifier comments, violating the project’s licensing documentation policy.

Suggested fix: Add an SPDX header as a YAML comment at the top of the file, e.g.,

SPDX-FileCopyrightText: 2025 Leonardo Carreras

SPDX-License-Identifier: MPL-2.0

Suggested change
name: Compliance checks
# SPDX-FileCopyrightText: 2025 Leonardo Carreras
# SPDX-License-Identifier: MPL-2.0
name: Compliance checks

Checked against the source: new workflow file has no SPDX-FileCopyrightText or SPDX-License-Identifier comments anywhere

stage: domain-modeling


on:
pull_request:
branches: [master, main]

jobs:
no-merge-commits:
name: No merge commits
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0

- name: Fail if branch contains merge commits
run: |
BASE=${{ github.event.pull_request.base.sha }}
HEAD=${{ github.event.pull_request.head.sha }}
MERGES=$(git log --merges "$BASE".."$HEAD" --oneline)
if [ -n "$MERGES" ]; then
echo "Error: merge commits found in this branch:"
echo "$MERGES"
echo ""
echo "Please rebase your branch instead of merging the target branch:"
echo ""
echo " git fetch upstream"
echo " git rebase upstream/master"
echo " git push --force-with-lease"
exit 1
fi

clean-notebook-outputs:
name: Notebooks have no saved outputs
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0

- uses: actions/setup-python@v5
with:
python-version: '3.x'

- name: Fail if a notebook touched by this PR has saved outputs
run: |
BASE=${{ github.event.pull_request.base.sha }}
HEAD=${{ github.event.pull_request.head.sha }}
NOTEBOOKS=$(git diff --name-only --diff-filter=d "$BASE" "$HEAD" -- '*.ipynb')
if [ -z "$NOTEBOOKS" ]; then

Check warning

Code scanning / SonarCloud

Python package manager scripts should not be executed during installation Medium

Omitting "--only-binary :all:" can lead to the execution of setup scripts. Make sure it is safe here. See more on SonarQube Cloud

Check warning

Code scanning / SonarCloud

Python dependencies should be locked to verified versions Medium

Using dependencies without locking resolved versions is security-sensitive. See more on SonarQube Cloud
exit 0
fi
pip install nbconvert

Check warning on line 56 in .github/workflows/compliance.yaml

View check run for this annotation

SonarQubeCloud / SonarCloud Code Analysis

Using dependencies without locking resolved versions is security-sensitive.

See more on https://sonarcloud.io/project/issues?id=sogno-platform_dpsim&issues=AZ-zXPvvP-vdCk_STPpt&open=AZ-zXPvvP-vdCk_STPpt&pullRequest=606

Check warning on line 56 in .github/workflows/compliance.yaml

View check run for this annotation

SonarQubeCloud / SonarCloud Code Analysis

Omitting "--only-binary :all:" can lead to the execution of setup scripts. Make sure it is safe here.

See more on https://sonarcloud.io/project/issues?id=sogno-platform_dpsim&issues=AZ-zXPvvP-vdCk_STPps&open=AZ-zXPvvP-vdCk_STPps&pullRequest=606

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pin nbconvert version in CI to avoid breakage
severity: medium · confidence: 80%

The CI step installs nbconvert without a pinned version ('pip install nbconvert'). This risks CI failures if nbconvert releases a breaking change or removes a previously available version. Pinning the version ensures reproducibility and aligns with best practices for dependency management in CI.

Suggested fix: Pin nbconvert to a known-good version in the CI workflow, e.g., 'pip install nbconvert==7.16.6'.

Suggested change
pip install nbconvert
pip install nbconvert==7.16.6

Checked against the source: the CI step runs pip install nbconvert without pinning a version

stage: build-deps

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pin nbconvert version to avoid CI breakage
severity: medium · confidence: 78%

The workflow installs nbconvert without a pinned version, which risks CI failures when a new nbconvert release introduces breaking changes. This violates DPsim's maintainability and reproducibility conventions.

Suggested fix: Pin nbconvert to a known-good version (e.g., 'nbconvert==7.16.4') to ensure the notebook stripping step remains stable across CI runs.

Checked against the source: the workflow installs nbconvert with pip install nbconvert and no version constraint

stage: numerics

python -m nbconvert --ClearOutputPreprocessor.enabled=True --inplace $NOTEBOOKS
if ! git diff --quiet -- $NOTEBOOKS; then
echo "Error: the following notebooks have saved outputs committed:"
git diff --name-only -- $NOTEBOOKS
echo ""
echo "Strip outputs before committing:"
echo ""
echo " jupyter nbconvert --ClearOutputPreprocessor.enabled=True --inplace <notebook.ipynb>"
echo ""
echo "Or install pre-commit hooks (see CONTRIBUTING.md) to do this automatically."
exit 1
fi
26 changes: 26 additions & 0 deletions .pre-commit-config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -48,3 +48,29 @@ repos:
hooks:
- id: markdownlint
args: [-r, "~MD013,~MD033,~MD024"]

- repo: local
hooks:
- id: clear-notebook-outputs
name: clear notebook outputs
language: python
additional_dependencies: ["nbconvert"]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pin nbconvert version in pre-commit hook to avoid breakage
severity: medium · confidence: 78%

The pre-commit hook declares nbconvert as an additional dependency without a pinned version ('additional_dependencies: ["nbconvert"]'). This risks breakage if nbconvert releases a breaking change. Pinning the version ensures the hook remains stable across environments.

Suggested fix: Pin nbconvert to the same version used in CI, e.g., 'additional_dependencies: ["nbconvert==7.16.6"]'.

Checked against the source: additional_dependencies lists nbconvert without a version pin

stage: build-deps

entry: python -m nbconvert --ClearOutputPreprocessor.enabled=True --inplace
files: \.ipynb$

- id: no-merge-commits
name: no merge commits (use rebase)
language: system
entry: >-
bash -c '[ ! -f .git/MERGE_HEAD ] || {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incorrect merge‑commit detection in pre‑commit hook
severity: high · confidence: 91%

The no-merge-commits pre‑commit hook checks for the existence of .git/MERGE_HEAD to reject merge commits. This file is only present during an ongoing merge operation and does not indicate that the current branch already contains merge commits. Consequently, the hook will not prevent feature branches that already include merge commits from being committed, violating the linear‑history policy enforced elsewhere (CI job no-merge-commits).

Suggested fix: Replace the check with a command that inspects the branch history for merge commits, e.g., git rev-list --merges --count HEAD or git log --merges --oneline HEAD ^$(git merge-base HEAD main) and fail if any are found.

Suggested change
bash -c '[ ! -f .git/MERGE_HEAD ] || {
entry: >-
bash -c 'if [ $(git rev-list --merges --count HEAD) -gt 0 ]; then
echo "\nError: merge commits are not allowed in DPsim.";
echo "Please rebase your branch onto the target branch instead:";
echo "\n git rebase upstream/master";
echo " git push --force-with-lease";
echo "";
exit 1;
fi'

Checked against the source: the no-merge-commits hook checks only .git/MERGE_HEAD and therefore misses existing merge commits in the branch history

stage: cpp-design

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no-merge-commits hook only checks MERGE_HEAD
severity: medium · confidence: 91%

The local pre-commit hook "no-merge-commits" determines a violation by testing the existence of .git/MERGE_HEAD. This file is present only while a merge is in progress, not when the branch already contains merge commits in its history. Consequently, a developer can commit a branch that includes merge commits and the hook will pass, relying solely on the CI job to catch the issue. This defeats the purpose of the pre‑commit guard and allows merge commits to slip into the repository if CI is bypassed.

Suggested fix: Replace the MERGE_HEAD test with a git log based detection of merge commits in the current branch, analogous to the CI job. For example, run git log --merges $(git merge-base HEAD @{u})..HEAD --oneline and fail if any output is produced.

Suggested change
bash -c '[ ! -f .git/MERGE_HEAD ] || {
entry: >-
bash -c 'MERGES=$(git log --merges $(git merge-base HEAD @{u})..HEAD --oneline); if [ -n "$MERGES" ]; then
echo "";
echo "Error: merge commits are not allowed in DPsim.";
echo "Please rebase your branch onto the target branch instead:";
echo "";
echo " git rebase upstream/master";
echo " git push --force-with-lease";
echo "";
exit 1;
fi'

Checked against the source: the local hook determines failure solely from .git/MERGE_HEAD, which is present only during an ongoing merge

stage: io-robustness

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improve no-merge-commits hook robustness
severity: medium · confidence: 82%

The no-merge-commits pre-commit hook checks for the presence of .git/MERGE_HEAD to detect merge commits. This file is not guaranteed to exist in all Git environments (e.g., shallow clones or CI runners with fetch-depth=1), which can cause the hook to silently pass even when merge commits are present. This undermines the linear-history policy.

Suggested fix: Replace the file-based check with a Git command that directly inspects the commit history, e.g. use 'git merge-base --is-ancestor' or 'git log --merges' to detect merge commits regardless of .git/MERGE_HEAD presence. Update the entry to a shell script that always uses 'git' commands and exits non-zero when merge commits are found.

Checked against the source: the hook only tests for .git/MERGE_HEAD, which detects an in-progress merge rather than merge commits already present in branch history

stage: realtime-resources

echo "";
echo "Error: merge commits are not allowed in DPsim.";
echo "Please rebase your branch onto the target branch instead:";
echo "";
echo " git rebase upstream/master";
echo " git push --force-with-lease";
echo "";
exit 1; }'
stages: [pre-commit]
always_run: true
pass_filenames: false
53 changes: 53 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
<!--
SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University
SPDX-License-Identifier: MPL-2.0
-->

# Contributing to DPsim

Thanks for your interest in contributing! Below are the essentials to get a pull request merged. For full detail see the [Development Guidelines](https://dpsim.fein-aachen.org/docs/development/guidelines/).

## Quick start

1. Fork the repository and clone your fork.
1. Run `pre-commit install` to activate automated checks (formatting, linear history guard, notebook output stripping).
1. Create a branch with a descriptive prefix (`feature/`, `fix/`, `docs/`).
1. Make your changes and commit using the conventional commit style (`feat:`, `fix:`, `docs:`, ...) with a sign-off:

```shell
git commit -s -m "fix: correct node voltage initialization in DiakopticsSolver"
```

1. Keep your branch up to date by rebasing; do not merge the target branch into your branch:

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

1. Open a pull request against `sogno-platform/dpsim:master`.

## Key requirements

- **Linear history**: merge commits in a feature branch are blocked by CI; rebase instead.
- **Sign-off**: every commit must include `Signed-off-by` via `git commit -s` ([DCO](https://developercertificate.org/)).
- **Formatting**: clang-format 17 for C++, black for Python, markdownlint for Markdown; all enforced by pre-commit.
- **SPDX headers**: new files must include a license header (see [guidelines](https://dpsim.fein-aachen.org/docs/development/guidelines/)).
- **No `std::cout` in C++**: use `SPDLOG_LOGGER_*` macros.
- **No saved notebook outputs**: strip outputs from `.ipynb` files before committing; pre-commit and CI both enforce this.
- **Contributions in forks only**: do not push feature branches to the main repository.

## AI-assisted contributions

DPsim follows the Linux Foundation [policy guidance on generative AI tools](https://www.linuxfoundation.org/legal/generative-ai), which permits AI-generated contributions and sets out what to check before making one. Two of its requirements bear directly on this project: the tool's terms must not restrict its output in ways that conflict with the [MPL-2.0](https://mozilla.org/MPL/2.0/), and where the output carries pre-existing third-party material you must have permission to contribute it and must supply the corresponding notice and attribution alongside your change. That guidance invites projects to add their own; the rest of this section is ours.

Using an assistant changes nothing about who is accountable for the result, and none of this is peculiar to AI. Code you adapted from a forum answer, a blog post or another project has always carried the same obligations, and an assistant is not a special case. You are the author of everything you submit: read it, build it, run the tests, and be ready to defend it in review exactly as if you had typed it. Do not open a pull request containing code you cannot explain. Your `Signed-off-by` line is a statement under the [DCO](https://developercertificate.org/) that you have the right to submit the work, so sign it only once the checks above hold.

Say so in the pull request description when a change is largely generated, so reviewers know where to look harder. Do not add AI co-author trailers to commit messages; the sign-off already identifies the author. Numerical results, validation notebooks and physical reasoning need the same scrutiny as code, and plausible-looking output is not evidence a model is correct.

Do not paste unpublished research, confidential data or third-party code you do not own into an external service.

## License

By contributing you agree your work is released under the [Mozilla Public License 2.0](https://mozilla.org/MPL/2.0/).
18 changes: 17 additions & 1 deletion docs/hugo/content/en/docs/Contribution guidelines/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,4 +8,20 @@ description: >
---

We'd love to accept your patches and contributions to this project.
Please send us a [pull request](https://github.com/sogno-platform/dpsim/pulls) or get in touch with us via mail or [slack](https://lfenergy.slack.com/archives/C054GB551TL) if you would like to contribute.
Please send us a [pull request](https://github.com/sogno-platform/dpsim/pulls) or get in touch with us via mail or [Slack](https://lfenergy.slack.com/archives/C054GB551TL) if you would like to contribute.

For detailed requirements on code style, pull request format, and the linear history policy, see [Development Guidelines]({{< relref "/docs/Development/guidelines" >}}).

# Quick start

1. Fork the repository and clone your fork.
1. Run `pre-commit install` to activate the automated checks (formatting, linear history guard, etc.).
1. Create a feature branch and make your changes.
1. Keep your branch up to date by rebasing; do not merge the target branch into your branch:

```bash
git rebase upstream/master
git push --force-with-lease
```

1. Open a pull request from your fork.
24 changes: 24 additions & 0 deletions docs/hugo/content/en/docs/Development/guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,30 @@ There are no strict formal requirements besides the following:
*/
```

1. **Linear History (no merge commits)**

DPsim maintains a linear git history.
Never merge the target branch into your feature branch — rebase instead:

```bash
git rebase upstream/master
git push --force-with-lease
```

A `pre-commit` hook enforces this automatically once you have run `pre-commit install`.

1. **No Saved Notebook Outputs**

Jupyter notebooks must be committed without saved cell outputs (images, plots, printed text).
Saved outputs bloat diffs and can break the notebook test collector, which re-executes notebooks and re-extracts their outputs.
Strip outputs before committing:

```bash
jupyter nbconvert --ClearOutputPreprocessor.enabled=True --inplace <notebook.ipynb>
```

A `pre-commit` hook does this automatically once you have run `pre-commit install`; CI also rejects any notebook that still has outputs saved.

# Creating New Releases (info for maintainers)

DPsim currently uses to [Semantic Versioning](https://semver.org/). The periodic creation of
Expand Down
Loading