Anshul
2e2ed36968
* Resolve the deployed commit after checkout and use that for the artifact lookup instead of github.sha. * publish_npm.yml builds from the checked-out commit instead of downloading a master artifact * derive version into files * Six files that were stale at 3.5.0 are now 3.5.1.
3.9 KiB
- Go through Github issues to verify bugs have been fixed and closed.
- Verify ManifoldCAD.org - check a few examples, run them, download a GLB and a 3MF.
- Verify our three.js example is functional.
- Verify our model-viewer example is functional - select Union and Intersection.
- Verify make-manifold is functional. Try dropping DragonAttenuation.glb in and verify you can select "View Manifold GLB" and that the dragon is still present while the backdrop is removed. Download the GLB.
- Run the Prepare release workflow from the Actions tab with the new version number. It sets the version in CMakeLists.txt, pyproject.toml, flake.nix, package.json and test-cmake.sh, refreshes the package-lock files, and opens a PR.
- Verify tests pass on that PR, manually trigger build_wheels CI, merge.
- On Github, draft a new release, make a new tag with the version number, add release notes, and publish.
- Check the Actions and verify that both PyPI and npm publishing actions ran successfully.
- Verify the npm package looks good - unpacked size should be close to 1MB.
- Verify PyPI package looks good - a bunch of built distributions ranging from ~600kB to ~1.1MB.
- If there's a problem with release deployment, the release workflows can be triggered separately, manually for any branch, under the Actions tab. See Deploying manually for the site deploy in particular.
Where the site is published
manifoldcad.org is served from the gh-pages branch, which holds several
builds side by side:
| Path | Updated | Contents |
|---|---|---|
/ (root) |
each published release | the current release, served at manifoldcad.org |
alpha/ |
every master commit that passes CI | unreleased build, for testing |
vX.Y.Z/ |
once, when that release is published | a frozen snapshot of that version |
Each is a complete copy of the site: the ManifoldCAD editor, the examples,
the benchmark dashboard, and both the C++ and TypeScript docs. A release
publishes twice, once to its own vX.Y.Z/ directory and once to the root,
so manifoldcad.org always serves the current release directly.
Subdirectory deploys erase their target before writing, so each holds exactly one build. The root deploy cannot, because clearing it would take the subdirectories with it, so there it overwrites in place instead.
Deploying manually
The Deploy documentation workflow can be run by hand from the Actions tab for a quick fix or a docs-only update, without cutting a release. It takes two inputs:
- ref - the branch or tag to build from, e.g.
v3.4.0 - destination_dir - the directory on
gh-pagesto publish into, e.g.v3.4.0
The target directory is erased and rebuilt, so the result is exactly what the chosen ref produces. Nothing outside that directory is affected.
Keep ref and destination_dir describing the same version. Publishing
master into v3.4.0/ would leave that directory claiming to be a release it
is not.
Typical uses:
- Fix a published version. Branch from its tag, commit the fix, then deploy that branch into the version's own directory. Useful for correcting documentation without a patch release.
- Backfill an old release. Deploy its tag into a matching directory so the version has a browsable copy of the site.
- Preview a branch. Deploy it somewhere disposable rather than over a directory that matters.
Builds from before the versioned layout existed assume they are served from the site root and will load the wrong assets from a subdirectory. Deploying such a tag needs the relative-path fix applied on top first.