Context
While adopting the template's CI in ptr727/KiCadLibrary — a data-only repo (a KiCad symbol/footprint library, no compiled code) — I mirrored the workflow set so the repo can stay in sync with the template per the usual downstream-sync flow.
What I found
The release orchestration is genuinely reusable and valuable to a non-.NET downstream:
get-version-task.yml (NBGV → SemVer2 + GitCommitId),- the two-phase publish model in
publish-release.yml (setup publish-plan → branch matrix; push smoke-only unless PUBLISH_ON_MERGE; weekly schedule + dispatch),
- the
github-release job pattern (check-existing → softprops/action-gh-release with target_commitish: GitCommitId, prerelease: branch != main),
build-datebadge-task.yml,- the
test-pull-request.yml shape (validate job + smoke build + check-workflow-status required-status aggregator).
But that orchestration is interleaved with .NET/Docker/PyPI/NuGet build specifics inside build-release-task.yml and build-executable-task.yml (e.g. dotnet publish ./Console/Console.csproj, 7z of the publish dir, the per-target enable_* matrix). A downstream that isn't .NET can't configure its way out — it has to fork and rewrite build-release-task.yml to swap the build step (in my case: stage the library files → zip → attach ptr727-KiCadLibrary-<SemVer2>.zip). The orchestration then drifts from upstream and the sync benefit is lost for exactly the files that carry the reusable logic.
Suggestion
Consider factoring the build from the release orchestration so the orchestration can be reused unchanged:
- a thin, swappable "produce artifact(s)" task (the only part a downstream overrides), and
- the version/package/release/date-badge orchestration that stays identical upstream and downstream.
Even just documenting the intended override seam (which task a non-.NET downstream is expected to replace, and which are meant to be verbatim) would reduce drift.
Minor, related: get-version-task.yml installs the full .NET SDK (setup-dotnet, dotnet-version: 10.x) purely to run NBGV, which is heavyweight for a downstream with no .NET — though NBGV does need the runtime, so this may be acceptable as-is.
Filing per the downstream-sync convention; close as out-of-scope if the template is intentionally .NET-only.
Context
While adopting the template's CI in ptr727/KiCadLibrary — a data-only repo (a KiCad symbol/footprint library, no compiled code) — I mirrored the workflow set so the repo can stay in sync with the template per the usual downstream-sync flow.
What I found
The release orchestration is genuinely reusable and valuable to a non-.NET downstream:
get-version-task.yml(NBGV →SemVer2+GitCommitId),publish-release.yml(setuppublish-plan → branch matrix; push smoke-only unlessPUBLISH_ON_MERGE; weekly schedule + dispatch),github-releasejob pattern (check-existing →softprops/action-gh-releasewithtarget_commitish: GitCommitId,prerelease: branch != main),build-datebadge-task.yml,test-pull-request.ymlshape (validate job + smoke build +check-workflow-statusrequired-status aggregator).But that orchestration is interleaved with .NET/Docker/PyPI/NuGet build specifics inside
build-release-task.ymlandbuild-executable-task.yml(e.g.dotnet publish ./Console/Console.csproj,7zof the publish dir, the per-targetenable_*matrix). A downstream that isn't .NET can't configure its way out — it has to fork and rewritebuild-release-task.ymlto swap the build step (in my case: stage the library files →zip→ attachptr727-KiCadLibrary-<SemVer2>.zip). The orchestration then drifts from upstream and the sync benefit is lost for exactly the files that carry the reusable logic.Suggestion
Consider factoring the build from the release orchestration so the orchestration can be reused unchanged:
Even just documenting the intended override seam (which task a non-.NET downstream is expected to replace, and which are meant to be verbatim) would reduce drift.
Minor, related:
get-version-task.ymlinstalls the full .NET SDK (setup-dotnet,dotnet-version: 10.x) purely to run NBGV, which is heavyweight for a downstream with no .NET — though NBGV does need the runtime, so this may be acceptable as-is.Filing per the downstream-sync convention; close as out-of-scope if the template is intentionally .NET-only.