chore: publish releases through GitHub Actions - #54
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Coverage Report for CI Build 33423545871Coverage remained the same at 54.128%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f184a9e4be
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Fetch remote branches | ||
| run: git fetch origin --depth=1 |
There was a problem hiding this comment.
Fetch enough history before testing branch ancestry
If the permitted branch advances after the release tag is pushed but before check_branch runs, this depth-one fetch retrieves only the new branch tip, leaving the tagged commit behind a shallow boundary. Consequently, git branch --contains "$GITHUB_SHA" cannot establish that origin/master or the release branch contains the tag, should_build remains empty, and a valid release is silently skipped. The git fetch --depth documentation confirms that this option limits history from each remote branch tip; fetch complete ancestry (for example with fetch-depth: 0) before performing the containment check.
Useful? React with 👍 / 👎.
| - name: Publish to npm | ||
| run: npx ocular-publish from-git |
There was a problem hiding this comment.
Make the publish step safe to rerun
If lerna publish fails after publishToNPM has successfully created the GitHub release—for example, after publishing only some of the three packages—rerunning this workflow invokes from-git again, but github-release.ts attempts the same release creation first and exits on GitHub's already-exists response before reaching npm. This defeats the existing partial-publication recovery logic in get-npm-dist-tag.ts; the workflow should tolerate an existing release or publish packages before creating it.
Useful? React with 👍 / 👎.
Goal
Align dev-tools releases with the tag-driven workflow used by the other vis.gl repositories, so a maintainer only creates the version commit and tag locally while GitHub Actions performs the npm publication.
Changes
publish-betaandpublish-prodto theocular-publish version-only-*modesv*tag workflow that verifies the tag belongs tomasteror a release branchocular-publish from-gitand the repository npm tokenValidation
yarn buildyarn lintyarn testgit diff --checkRelease follow-up
After this lands,
yarn publish-betaonmasterwill create and pushv2.0.0-alpha.7; this workflow will then publish the packages to npm under the beta tag.