ci: manage releases and version bumps with release-please - #608
ci: manage releases and version bumps with release-please#608leonardocarreras wants to merge 1 commit into
Conversation
Signed-off-by: Leonardo Carreras <leonardo.carreras@eonerc.rwth-aachen.de>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
DPsim LLM review
Claim vs. code: The diff does not show the promised changelog-sections mapping to existing Keep a Changelog headings, and it does not update pyproject.toml itself to 1.2.1 in this patch.
TL;DR: Three reports collapse to one real issue: the new release-please manifest is missing the required SPDX header, while the config-file SPDX note is separate but low-risk; no other correctness, scheduling, or release-flow problems were raised. The main risk is REUSE/licensing compliance for the newly added JSON files.
Found 4 medium (4 anchored to lines below).
🟡 Suggestions
- Add missing SPDX header to release-please config
[medium · 95% confidence]inrelease-please-config.json:1(details inline) - Add SPDX header to new manifest file
[medium · 95% confidence]in.release-please-manifest.json:1(details inline) - Missing SPDX header in new JSON file
[medium · 95% confidence]in.release-please-manifest.json:1(details inline) - Missing SPDX header in new JSON manifest
[medium · 95% confidence]in.release-please-manifest.json:1(details inline)
Claim vs. implementation
- Claimed: Replace manual version bumps with release-please, keeping CHANGELOG.md and triggering PyPI publishing via workflow_dispatch on new tags.
- Done: Adds release-please config/manifest and workflow, updates publish workflow for dispatch, pins target branch to master, excludes CHANGELOG.md from markdownlint, and marks CMakeLists.txt/pyproject.toml as versioned files.
- Difference: The diff does not show the promised changelog-sections mapping to existing Keep a Changelog headings, and it does not update pyproject.toml itself to 1.2.1 in this patch.
How this review was produced
13 specialized finder passes raised 13 findings over the diff and the full changed sources. After de-duplication, 13 were re-checked against the current file and the base-class / interface headers it inherits (code as truth), escalating survivors to a stronger model: 9 refuted as unsupported, 4 kept (0 tentative).
Refuted by verification:
- Add workflow_dispatch trigger to publish-testpypi job condition (.github/workflows/publish_to_pypi.yaml): The comment already matches the added workflow_dispatch trigger at lines 10-11 and the job condition at line 78.
- Simplify publish-pypi job condition for clarity (.github/workflows/publish_to_pypi.yaml): The parentheses are present in the current source and are part of the changed line, but they are a harmless readability choice, not a defect.
- Clarify workflow dispatch comment (.github/workflows/release-please.yaml): The comment is present in the file and the step explicitly runs publish_to_pypi.yaml, so the wording is already tied to that workflow context.
- Clarify comment about workflow_dispatch behavior (.github/workflows/release-please.yaml): The file contains the exact comment and the next step dispatches the publish pipeline only when a release tag is created, matching the intended behavior.
- Clarify comment about workflow_dispatch behavior (.github/workflows/publish_to_pypi.yaml): Line 10 explicitly says Release Please dispatches this at the new tag and that the pushed tag starts no run by itself, which is consistent with the workflow_dispatch trigger.
- Add workflow_dispatch trigger to publish-testpypi job (.github/workflows/publish_to_pypi.yaml): The publish-testpypi job condition explicitly includes github.event_name == 'workflow_dispatch' on line 78.
- Add missing SPDX header to release-please workflow (.github/workflows/release-please.yaml): The workflow file already has SPDX-FileCopyrightText and SPDX-License-Identifier headers at the top.
- Add SPDX header to new workflow file (.github/workflows/release-please.yaml): The new YAML file begins with the required SPDX header lines, so the claimed omission is not present.
- Add workflow_dispatch trigger to publish-pypi job condition (.github/workflows/publish_to_pypi.yaml): line 10 states workflow_dispatch is expected at the new tag, so the tag guard on the PyPI publish job is intentional
Automated, non-blocking review. May be wrong. Models: find mistral-small-4-119b-2603, gpt-oss-120b → verify gpt-5.4-mini → final gpt-5.5.
| @@ -0,0 +1,71 @@ | |||
| { | |||
There was a problem hiding this comment.
Add missing SPDX header to release-please config
severity: medium · confidence: 95%
The new release-please configuration file lacks the required SPDX license identifier and copyright header. DPsim requires SPDX headers in all new files to comply with REUSE and licensing policy.
Suggested fix: Add the SPDX header to the release-please-config.json file as shown in other DPsim configuration files. The header should be:
// SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University
// SPDX-License-Identifier: MPL-2.0
| { | |
| // SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University | |
| // SPDX-License-Identifier: MPL-2.0 | |
| { | |
| "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", |
Checked against the source: new release-please config starts directly with JSON and contains no SPDX-FileCopyrightText or SPDX-License-Identifier header
stage: tests-docs-coverage
| @@ -0,0 +1,3 @@ | |||
| { | |||
There was a problem hiding this comment.
Add SPDX header to new manifest file
severity: medium · confidence: 95%
The new file .release-please-manifest.json lacks an SPDX header. All new source, script, and workflow files must carry an SPDX header with SPDX-FileCopyrightText and SPDX-License-Identifier in the file's own comment syntax (# for JSON).
Suggested fix: Add the SPDX header at the top of the file using the correct JSON comment syntax:
// SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University
// SPDX-License-Identifier: MPL-2.0
| { | |
| // SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University | |
| // SPDX-License-Identifier: MPL-2.0 | |
| { | |
| ".": "1.2.1" | |
| } |
Checked against the source: new manifest starts directly with JSON and contains no SPDX-FileCopyrightText or SPDX-License-Identifier header
stage: process-compliance
| @@ -0,0 +1,3 @@ | |||
| { | |||
There was a problem hiding this comment.
Missing SPDX header in new JSON file
severity: medium · confidence: 95%
All new source files must include an SPDX license header per project policy. The newly added .release-please-manifest.json lacks the required SPDX-FileCopyrightText and SPDX-License-Identifier lines, violating the Development/guidelines rule for new files.
Suggested fix: Add the appropriate SPDX header comment at the top of the JSON file, matching the project's licensing (MPL-2.0).
| { | |
| # SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University | |
| # SPDX-License-Identifier: MPL-2.0 | |
| { | |
| ".": "1.2.1" | |
| } |
Checked against the source: new manifest starts directly with JSON and contains no SPDX-FileCopyrightText or SPDX-License-Identifier header
stage: domain-modeling
| @@ -0,0 +1,3 @@ | |||
| { | |||
There was a problem hiding this comment.
Missing SPDX header in new JSON manifest
severity: medium · confidence: 95%
New source files must contain an SPDX license header using the file's comment syntax. JSON has no native comment syntax, but the project convention requires a header (e.g. // SPDX-FileCopyrightText ... // SPDX-License-Identifier ...) at the top of the file. The manifest currently starts directly with JSON content, violating the SPDX requirement and breaking automated license compliance checks.
Suggested fix: Add a SPDX header as the first two lines using // comments before the JSON object. This will satisfy the project's SPDX policy while remaining ignored by JSON parsers.
| { | |
| // SPDX-FileCopyrightText: 2026 Institute for Automation of Complex Power Systems, EONERC, RWTH Aachen University | |
| // SPDX-License-Identifier: MPL-2.0 | |
| { |
Checked against the source: new manifest starts directly with JSON and contains no SPDX-FileCopyrightText or SPDX-License-Identifier header
stage: process-compliance
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #608 +/- ##
==========================================
+ Coverage 72.75% 72.83% +0.08%
==========================================
Files 497 497
Lines 32305 32305
Branches 17470 17470
==========================================
+ Hits 23503 23530 +27
+ Misses 8801 8774 -27
Partials 1 1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
1 participant
Replaces manual version bumps with release-please. It opens a pull request that bumps CMakeLists.txt and pyproject.toml and maintains CHANGELOG.md, and merging that pull request is the release decision. The manifest starts at 1.2.1, matching both files and the last tag.
CHANGELOG.md is kept, not replaced. changelog-sections maps the conventional commit types onto the Keep a Changelog headings the file already uses. The version header line cannot be matched and will differ from the existing entries.
A tag pushed with GITHUB_TOKEN starts no workflow run, so the workflow dispatches publish_to_pypi.yaml at the new tag instead. That workflow gains a workflow_dispatch trigger, and both publish jobs now accept it, since they were gated on the push event and a dispatch would have built the wheels and then skipped publishing. No personal access token is needed.
target-branch is pinned to master so a manual dispatch cannot release unmerged code. The generated changelog trips MD012, so it is excluded from the markdownlint hook. SPDX for it belongs with the REUSE rollout in #602.
Depends on the conventional commits enforcement pull request, which has to land first: without it the version is derived from only the commits that happen to parse.