Repository navigation
Conversation
XRobot 1.0 names the earlier CMake multi-board project; messages about the pip package now write it as xrobot. Hints for a Module made before xrobot 1.0 suggest its master branch instead of @dev.
The generated header's digest covers the bytes of its depends; with the Git for Windows default core.autocrlf=true, a Module checkout on Windows gave a different digest than on Linux.
Write the pip package as xrobot and suggest a Module's master branch
Clone Modules with core.autocrlf=false
…s and the extension States that dev is merged into master with a merge commit and then fast-forwarded, why squash and rebase break the BSP lock check, that new tags are lowercase (LibXR included), that templates merge dev into master, and how the VS Code extension release is created from a tag.
RELEASE.md: merge commits, fast-forward dev, lowercase tags, templates and the extension
The 1.0 release published no BSP firmware: only a v tag or a Release published it, and no BSP was tagged. A push to master (or main), which receives dev only at a release, now tags the next patch version (v1.0.0 for the first) in the release job and publishes the firmware; a merge commit that already has a v tag is left to the run of that tag. RELEASE.md step 6 says so.
Publish BSP firmware on the push to master
The three contexts (dependency modules, LibXR, the XRobot tools) used to default to master, so a Module on a feature branch could not test against that branch. One rule now covers all of them: a pull request takes its target branch, a tag push takes master, every other event takes the current branch, and each repository falls back to dev when a lookup on github.com finds no branch of that name (same-or-dev). The ref inputs default to empty, which follows the rule, and a value still overrides it; a resolution step before the checkouts writes the final refs to GITHUB_OUTPUT and prints them for debugging. The probe used to configure without a build type, giving -O0 and no assertions. The new build-type input defaults to RelWithDebInfo whose compile options are replaced by -O2 -g (no NDEBUG, so assert() and eigen_assert stay active) plus LIBXR_DEBUG_BUILD=ON; another build type is passed through untouched and cmake-options still come last.
A same-or-dev request used to pass the branch it actually resolved to as the context of its dependencies, so a middle Module without the feature branch pulled its whole tail down to dev while another path resolved the same Module on the feature branch; one Module could end up at two commits in one resolution. same, same-or-dev and explicit tags or commits now pass the original context on, and every layer looks for its own branch of that name before falling back to dev; only an explicit branch name still changes the context of the next layer. The conflict error names the repository in the chain that lacks the branch and fell back to dev.
The candidates of a pointer parameter were written &name, and a user who copied that into the YAML without quotes turned the value into an empty YAML anchor. The generator already takes the address of a bare name for a pointer parameter, so the hints now offer the bare name; constructor selection matches a bare name by the type after taking its address, and the quoted '&name' keeps working. A line whose anchor has no value, the shape the old hint produced, is reported as the empty YAML anchor it is, with the bare name suggested.
The line and column of a YAML error in the MODULE MANIFEST were relative to the manifest block and got dropped, so a hand-written description with an unquoted colon was reported without a position. The error now names the real line and column in the header file, pointing at the offending character, and keeps the hint about quoting values that contain ": " or "#"; the user's header is never rewritten.
A branch-following request in a BSP that is not a Git repository kept its locked commit with a warning on every setup, and --update kept it just as silently. Keeping the lock without --update is the normal case, so the warning is gone; --update would re-resolve those requests by the BSP branch, which outside Git and without --context-ref is impossible, so sync now fails before any Module is touched and asks for --context-ref refs/heads/<branch>. Requests that stay pinned, like the modules another --update name excludes, are not affected.
A Module whose HEAD is a local commit on no remote branch or tag blocked every setup, and the only advice was to push it. --discard-local <MODULE> now names the Modules whose unpushed local commits may be thrown away: their commit ids and changed files are printed, then the resolved commit is checked out directly without a backup branch. Uncommitted changes are still refused, and Modules the option does not name keep the refusal, which now also mentions --discard-local and what it discards.
sync seeded a new constructor parameter with its C++ default written as
one YAML string, so a brace default like {0.55} had to be quoted and
showed up as '{0.55}' in the configuration. The inserted defaults now go
through the generator's initializer parser: a positional initializer
becomes a YAML list and a designated one a mapping with field names, so
no quotes are needed and gen reads back the very same expressions. A
designated initializer is only expanded for a type the index locates,
since a nested mapping of a type outside the index cannot be verified;
scalars stay C++ code text as before, and values the parser cannot
expand (T{...}, the empty {}, repeated fields) stay as written without a
hint.
A Module merged with a merge commit keeps its feature-branch commits on the release line, so the BSP --frozen --release-ref gate passes without refreshing the lock; only squash, rebase or another history rewrite needs the refresh command the gate error prints, and a downstream pull request is re-run manually after the upstream merge. Document the pointer parameter notations: the bare name whose address the generator takes, the quoted '&name' that still works, and nullptr for an unused optional dependency.
The option for Modules parked on unpushed local commits was missing from the command overview, so the CLI help was its only description. The new row mirrors the option help, like the other rows mirror their commands.
The last-segment match folds the case, so one short name can match several locked Modules, and the name check treated several matches the same as none: it claimed the Module was not in xrobot.lock. Name the match ambiguous and list the matched ids, mirroring the ambiguous Module/Package errors; a name matching nothing still reports that it is not in the lock.
The --update name check treated no match and several matches the same, blaming a mistyped id when a short name like A actually hit two locked Modules. Split it like --discard-local: no match keeps the not-in-the-lock error, several matches raise the ambiguous error with the matched ids listed.
The name claimed the unpushed local commits were discarded, but materialize() only checks out the target commit: the commits stay on their local branch, and on a detached HEAD they are recoverable through the reflog (git keeps it for at least 30 days by default). The option, the arguments, the texts and the tests now use --leave-local, the printout names the branch or the reflog with the original HEAD commit, and the refusal hint no longer claims the commits are discarded. The option is unreleased, so the old name keeps no alias.
--leave-local still refuses a Module with uncommitted changes, so a checkout with both unpushed commits and local modifications cannot be moved at all. With --force, a named Module that has to move gets its tracked modifications reset and its untracked files cleaned, inside submodules too and without -x so ignored files survive, after the changes to discard are printed from git status --porcelain; if changes remain after the discard, the Module is not moved. A named Module already at its target keeps its changes even with --force, and Modules --leave-local does not name are still refused. --force alone fails before any Module is touched. The README row documents the option.
git submodule foreach with reset --hard and clean -fd never switches a submodule's HEAD, so a submodule parked at another commit (a gitlink modification in the parent) survived the discard and made --leave-local --force throw away the other changes and then refuse to move the Module. Run git submodule update --init --recursive --force first, so the submodules return to the commits the parent records before the foreach wipes what remains. A test with local repositories now covers all three submodule cases - a tracked modification, an untracked file and a HEAD parked at another commit - plus the ignored file that has to survive; it allows the file protocol in the inherited environment only, because production submodules come over https.
Module CI: resolve the contexts from the event and build with assertions
Fix same-or-dev chains, pointer hints, manifest errors, setup edge cases and synced defaults
Bump the version to 1.0.1
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
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.
Release xrobot 1.0.1 (with LibXR v2.0.1 and CodeGenerator 6.0.1). Merge after the LibXR release (RELEASE.md step 3); a GitHub Release
v1.0.1on the merge commit publishes to PyPI, thenv1moves to the same commit (step 4). After the merge, dev is fast-forwarded to master.Candidate: dev
70eaffef34c0dc077a43a3213318b32b952e793f(pyproject.toml1.0.1,xr-syntax==0.2.0). master's two extra commits are merge commits of #99 and #104 whose trees equal their dev parents.Changes since 1.0.0
module-ci.yml): dependencies, LibXR and the tools follow one context rule (pull request: target branch; push: same branch or dev; tag: master; refs stay overridable); default build RelWithDebInfo with-O2 -gandLIBXR_DEBUG_BUILD=ON, new inputbuild-type(Module CI: resolve the contexts from the event and build with assertions #109).header:line:column; BSP outside Git with--update;setup --leave-local <Module...> [-f]; synced defaults as native YAML; ambiguous Module names reported; release-gate and pointer notation docs.xrobot(Write the pip package as xrobot and suggest a Module's master branch #105); Modules cloned withcore.autocrlf=false(Clone Modules with core.autocrlf=false #106); RELEASE.md rules (RELEASE.md: merge commits, fast-forward dev, lowercase tags, templates and the extension #107); BSP firmware published on the push to master (Publish BSP firmware on the push to master #108); version 1.0.1 (Bump the version to 1.0.1 #111).Acceptance
All six RELEASE.md checks pass and
tools/check_release.pyagrees with the record (details in the LibXR release PR): packages CI green on70eaffef; Module matrix 64/64 with the new Module CI settings and LibXR2712e5c5; BSPs regenerated and built with xrobot 1.0.1 (19/19 + 15/15).