The Problem
OpenArm is a robotic arm hardware platform whose CAD files live on Google Drive, not in the repository. The repo's job is to make those files discoverable, keep the v1/v2 releases organized, and provide tooling for contributors who want to build, print, or customize the arm. The central pain point is coordination: CAD file management, release versioning, and community contributions all need to stay in sync without the CAD assets being version-controlled in Git.
What This Does
This is a documentation and release-orchestration repository, not an application. The README.md points to Google Drive folders for v1 and v2 CAD files, each containing STEP assemblies, STL print files, attachments, and wiring diagrams. Full specs and assembly guides live at docs.openarm.dev/hardware.
The dev/ directory contains the only real code. dev/google-drive-files/generate-file-ids.rb generates a TSV of Google Drive file IDs, and dev/release.sh orchestrates the release process. The .github/workflows/release.yaml runs that script in CI, and .github/dependabot.yml keeps the Ruby dependency current.
How It Is Wired
This repository has no application runtime. The only executable paths are the release workflow and the two dev scripts. The Ruby script generate-file-ids.rb likely reads the Google Drive API to produce file-ids.tsv. The shell script release.sh is the release entry point, invoked by .github/workflows/release.yaml on tag pushes. The import graph is empty: 0 internal modules, 0 import edges, 0 circular dependencies, across 2 code files. The wiring beyond those two scripts has not been mapped for this repository yet.
File-by-file responsibility:
dev/release.sh— release orchestration, called by CIdev/google-drive-files/generate-file-ids.rb— generatesfile-ids.tsvfrom Google Drivedev/google-drive-files/Gemfile— Ruby dependencies for the ID generator.github/workflows/release.yaml— CI entry point that runs the release scriptREADME.md,CONTRIBUTING.md,CODE_OF_CONDUCT.md,LICENSE.txt— project governance and documentation
How To Use It
There is no application to run locally. The repository is consumed through its documentation links and the GitHub Actions workflow. The dev/ scripts are internal tooling; the Gemfile implies bundle install inside dev/google-drive-files/ before running the Ruby script, but no README documents that flow. Release is triggered by pushing a tag, which fires .github/workflows/release.yaml. No environment variables or configuration files are documented.
Real-World Use
A contributor wants to add a camera mount for the v2 arm. They download the STL from the Google Drive link in README.md, modify it in their CAD tool, then submit a pull request with the new assembly file. Maintainers review it, and on the next release tag, release.yaml runs dev/release.sh to update the file IDs and publish the release.
Code Health & Issues
Static analysis found 1 medium finding: duplicated code blocks. dev/google-drive-files/generate-file-ids.rb and dev/release.sh share 5 repeated 6-line blocks. The fix is to extract shared helpers.
The audit also reports:
- High — No lockfile beside
dev/google-drive-files/Gemfile. Unlocked ranges mean tested and shipped transitive dependencies can differ. Fix: commit the generated lockfile. - Medium — No dependency vulnerability scan in
.github/workflows. Fix: adddependency-review-actionon pull requests orosv-scanneron push. - Low —
.github/workflows/release.yamldeclares notimeout-minutes. A wedged job runs to the six-hour platform default. Fix: set a realistic bound per job.
No tests exist, which is consistent with a documentation and release-orchestration repo. No secrets are committed. The license is CERN Open Hardware Licence v2.
The Bottom Line
This is a well-organized hardware documentation repo with a small, functional release pipeline. The duplicated dev scripts and missing lockfile are minor but worth fixing. It is not a codebase anyone develops against; it is the coordination point for a hardware project whose actual artifacts live elsewhere.