feat: tokn release + binaries CI#69
Conversation
Only apply repo subpath base when GITHUB_PAGES is set; default to `/` so Cloudflare subdomain builds resolve CSS from `/assets/`. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
CodeAnt AI is reviewing your PR. |
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
| const name = repo.split('/')[1] | ||
| return `/${name}/` | ||
| } | ||
| if (process.env.PHENOTYPE_CUSTOM_DOMAIN === 'true') return '/' |
There was a problem hiding this comment.
Suggestion: The custom-domain detection is tied to PHENOTYPE_CUSTOM_DOMAIN, which appears to be a copy-paste variable name unrelated to this repo and is not set anywhere else. This makes the custom-domain branch effectively unreachable, so GitHub Pages builds with a custom domain can incorrectly use a /{repo}/ base and produce broken asset/doc links. Use the correct project-specific env var (or a generic one consistently used by your workflows) for this check. [inconsistent naming]
Severity Level: Major ⚠️
❌ GitHub Pages custom-domain docs served with incorrect base path.
❌ VitePress-generated links resolve under `/{repo}/` breaking navigation.
⚠️ Requires CI workaround setting DOCS_BASE or VITEPRESS_BASE manually.Steps of Reproduction ✅
1. From the docs project, run the build script defined in `docs/package.json:5-9` (`npm
run docs:build`), which executes `vitepress build .` and loads
`docs/.vitepress/config.ts:1-19`.
2. Configure the build environment for a GitHub Pages project site by setting
`GITHUB_PAGES=true` and `GITHUB_REPOSITORY=Tokn/Tokn`, while leaving `DOCS_BASE` and
`VITEPRESS_BASE` unset and not defining any `PHENOTYPE_CUSTOM_DOMAIN` variable (no such
variable is referenced anywhere else in the repo per `grep` under `/workspace/Tokn`).
3. During the build, `resolveDocsBase()` in `docs/.vitepress/config.ts:4-10` runs:
`explicit` is `undefined` because `DOCS_BASE` and `VITEPRESS_BASE` are unset, the check
`process.env.PHENOTYPE_CUSTOM_DOMAIN === 'true'` on line 7 evaluates to false because
nothing in the repo or workflows sets this variable, so the function falls through to line
9 and returns `"/Tokn/"` due to `GITHUB_PAGES === 'true'`.
4. The exported VitePress config at `docs/.vitepress/config.ts:15-19` uses `base:
docsBase`, so the generated site hardcodes links like `/Tokn/wiki/` and `/Tokn/api/`; when
the site is actually published at the root of a custom domain (e.g.,
`https://docs.example.com/`), these links point to the wrong paths and produce broken
navigation and asset URLs.(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/.vitepress/config.ts
**Line:** 7:7
**Comment:**
*Inconsistent Naming: The custom-domain detection is tied to `PHENOTYPE_CUSTOM_DOMAIN`, which appears to be a copy-paste variable name unrelated to this repo and is not set anywhere else. This makes the custom-domain branch effectively unreachable, so GitHub Pages builds with a custom domain can incorrectly use a `/{repo}/` base and produce broken asset/doc links. Use the correct project-specific env var (or a generic one consistently used by your workflows) for this check.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
CodeAnt AI finished reviewing your PR. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 087ecda3d2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| with: | ||
| ref: ${{ github.ref }} | ||
| secrets: | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
Use a non-GITHUB_TOKEN release credential
Because .github/workflows/release-attestation.yml listens for release: published, releases created by this workflow need to emit a follow-on release event. GitHub suppresses workflow runs triggered by events created with the default GITHUB_TOKEN, and the action's docs call out that a PAT is needed for release.published subscribers, so every automated v* release will upload binaries but skip the SLSA/provenance attestation workflow.
Useful? React with 👍 / 👎.
| - name: Upload release asset | ||
| uses: softprops/action-gh-release@v2 | ||
| with: | ||
| files: dist/${{ matrix.artifact_name }} |
There was a problem hiding this comment.
Pass the dispatch ref as the release tag
When binaries.yml is run manually with the advertised ref input, checkout builds that ref, but action-gh-release still defaults its target tag to github.ref_name because this step never passes tag_name. Running the workflow from main with ref: v1.2.3 therefore uploads to the wrong release/tag (or fails on a branch ref), so the manual rebuild path cannot publish the binary for the ref it just built.
Useful? React with 👍 / 👎.
User description
release.yml + binaries.yml (matrix GH-release binaries) for the Tokn ledger CLI.
CodeAnt-AI Description
Release builds now publish binaries from tags and docs load correctly on custom domains
What Changed
v*tag is pushed, and they publish the CLI binaries as release assets for Linux, macOS, and Windows.Impact
✅ Easier tagged releases✅ Downloadable CLI binaries on release pages✅ Fewer broken docs assets on custom domains💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.