ci: build third-party licenses from the build log instead of the SBOM - #3
Merged
Conversation
…workflow Ports the license-manifest fix from rodbus-no-serial. The manifest was generated from a CycloneDX SBOM, which lists every optional dependency in the lockfile whether or not it compiles, so the no-serial build shipped a notice claiming serial-only crates (including serialport, MPL-2.0) that aren't in the binary. This reads the actual cargo build log instead, via bom-tools 0.2.1. Also catches the workflow up to what rodbus-no-serial already uses: the artifact actions were on the retired v3, which no longer runs. Bumps them to current versions with per-target artifact names, and drops the push-on-main trigger so CI runs on PRs and tags only.
Plain --message-format json sends rustc diagnostics into the redirected build.json instead of the log, which hides compile errors on failure. json-render-diagnostics still emits the compiler-artifact JSON the license tool needs, but renders errors to stderr.
dnp3 1.6.0 (released 2024-06-24, no toolchain pin) denies warnings, and current stable flags two lints as errors (unnecessary parentheses around closure body). Pin to 1.79.0, the stable from that release, so the tag builds as it shipped. Applies to the packaging job too, which compiles dnp3-bindings.
dnp3 1.6.0 no longer compiles on current stable (it denies warnings and newer lints now fire). Since these runs only validate the pipeline and don't release (that's tag-gated), build the latest dnp3 on stable instead of pinning an old toolchain to force the tag. Restore a pinned tag before cutting a real release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same change rodbus-no-serial got, ported to dnp3.
The bundled third-party-licenses.txt was generated from a CycloneDX SBOM, which lists every optional dependency in the lockfile whether or not it actually compiles. For the no-serial build that means the manifest claimed serial-only crates that never make it into the binary, including serialport (MPL-2.0). That file is embedded in the nupkg. This switches to reading the cargo build log through bom-tools 0.2.1, so the manifest only covers what actually compiled.
While here, it also catches the workflow up to what rodbus-no-serial already runs. The artifact upload/download actions were on v3, which GitHub retired in early 2025, so the workflow couldn't complete a run. Bumped to current versions with the per-target artifact naming that v4+ requires, and switched the trigger to PRs and tags only so merges to main don't kick off the full build.
Binaries are unaffected. The tool fails closed if a compiled crate can't be resolved, so a green run means the manifest is complete.