Conversation
Anomaly7
marked this pull request as draft
September 2, 2026 22:07
Anomaly7
marked this pull request as ready for review
September 2, 2026 22:08
diyaseb285
self-requested a review
September 3, 2026 16:47
diyaseb285
previously approved these changes
Sep 5, 2026
MeelaParker
previously approved these changes
Sep 5, 2026
MeelaParker
left a comment
MeelaParker
left a comment
Collaborator
There was a problem hiding this comment.
Overall, the Windows implementation looks good! I noticed that two automated checks were unsuccessful. The parity script could not run because of a permission error, and the GitHub runner has Docker 28.0.4 while the bootstrap script requires at least 29.3. It looks like small ci setup issues, but I wanted to flag them so the automated checks can run successfully.
- Mark scripts/ci/*.sh executable so the compose parity and smoke-test jobs can run them on the Linux runner (permission denied before). - Downgrade the Docker >= 29.3 server version check to a warning on GitHub Actions, whose runners ship Docker 28.x. The API range check still applies there, and local runs still enforce the minimum. - Point the fortress workflow at scripts/environment/status_gazebo_fortress.sh, where the script actually lives. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anomaly7
dismissed stale reviews from MeelaParker and diyaseb285
via
September 24, 2026 17:31
856223d
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
The ign fortress workflow was failing in seconds because the status script targeted control-systems-dev, a service that no longer exists in compose.linux.yaml (renamed to canopen-sim in 303ba93). - Default to canopen-sim. - Drop the /dev/dri device mapping via a !reset override when the host has no GPU (hosted runners); nothing checked here needs it. - canopen-sim gets Fortress through ros-humble-ros-gz without recommends, so check the installed ros-gz packages, the Gazebo Sim 6 libraries and ros_gz_sim instead of requiring the ignition-fortress metapackage and ign CLI. ign gazebo is still exercised if present. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ntain permissions' Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
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
4 participants
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.
Adds Windows support for the CANopen simulation via a new compose.windows.yaml that swaps X11, host networking, and GPU passthrough for Docker Desktop equivalents (VcXsrv, bridge networking, software rendering), backed by a CI parity and smoke-test gate that keeps it in sync with compose.linux.yaml. Also fixes a real CRLF line-ending bug that broke the entrypoint script's shebang on Windows checkouts (.gitattributes), updates docs with a full Windows setup and troubleshooting section, and corrects a couple of stale compose.yaml references left over from the linux/windows split. Verified end-to-end: container builds and runs, both workspaces compile, and RViz renders the motor correctly through VcXsrv, matching the ticket's screenshot.