ci: publish a nakamir-suffixed package built against local sk_renderer - #7
Merged
Conversation
The build had no way to produce the configuration Nakamir actually consumes. sk_renderer is auto-detected as a sibling of the repo root, which sits outside the workspace, so CI checks it out inside and moves it into place. Its ref is an input because only the consuming repo knows which pair of revisions is valid. Set-Version gains a suffix that extends the prerelease label instead of replacing it, keeping the result ordered after the upstream build it came from. The header macros are numeric and cannot carry it, so Get-Version now defers to the csproj whenever it extends the header version, which keeps the .nupkg path in step with what dotnet pack emits. Both stay byte-identical without a suffix. The push target is now a parameter so the feed is a caller decision.
GitHub Packages rejects a push whose nuspec carries no repository element. SourceLink is already referenced, so publishing its resolved URL fills that in without hardcoding an owner, which keeps forks and upstream merges correct. It also records the commit, tying a published package to the revision it came from.
The three native jobs never pack, so passing -suffix to their Set-Version calls had no effect. The workflow_call copies of suffix and skRendererRef are never supplied by nightly_build or release_build; nugetSource stays declared there so its upload target does not resolve to an empty string.
Publishing to a GitHub Packages feed in the workflow's own org needs no PAT. Callers that set NUGET_KEY, such as nightly_build and release_build pushing to nuget.org, are unaffected.
Build-Nuget re-stamps the version from the numeric components alone, which dropped the suffix the workflow had just written and left the computed nupkg path pointing at a file pack never produced.
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.
Lets this fork publish the configuration Nakamir actually consumes, so the
consumer can restore StereoKit as a package instead of compiling StereoKitC from
source on every CI run.
Today the pipeline can only build vanilla StereoKit against the CPM-pinned
renderer. Nakamir builds against
sk_renderer, whichCMakeLists.txtdetects asa sibling of the repo root — a path outside the Actions workspace, and so out of
reach of
actions/checkout. Each native job now checks the renderer out insidethe workspace and moves it into place. Its ref is an input rather than a pin
because only the consuming repo knows which pair of revisions is valid.
Versioning
Set-Version.ps1takes a-suffixthat extends the prerelease label instead ofreplacing it, following the convention already used for the forked PSI packages
(
Microsoft.Psi.Audioships as0.19.100.7-beta.nakamir). The package ID staysStereoKit; only the version distinguishes it.Checked against
NuGet.Versioning, ascending:So a suffixed build sorts after the upstream build it came from, and the trailing
counter allows a re-release when only
sk_renderermoved. It sorts below thenext upstream preview, so consumers must pin exactly rather than float.
The numeric
SK_VERSION_*macros instereokit.hcannot carry a suffix, andGet-Version.ps1reads them to compose the.nupkgfilename — which would haveleft
dotnet nuget pushlooking for a filedotnet packnever produced. It nowdefers to the csproj whenever that extends the header version. Both scripts are
byte-identical to before when no suffix is passed.
Publishing
Build-Nuget.ps1takes a-source, defaulting to nuget.org, so the feed is acaller decision.
PublishRepositoryUrlis enabled because GitHub Packagesrejects a nuspec with no repository element; SourceLink was already referenced,
so its resolved URL is used rather than a hardcoded owner, keeping forks and
upstream merges correct. It also records the commit, which ties a published
package back to the revision it was built from.
Verification
actionlintreports nothing new; the three findings onbuild.ymlpredate this branch<repository type="git" url="https://github.com/Nakamir-Code/StereoKit.git" commit="88db9e6…" />No workflow has been dispatched yet —
NUGET_KEYneeds a token withwrite:packagesbefore the first publish.