Fix Tauri CI

[tachyons]

Fixes #

Describe the changes you have made in this PR -

Screenshots of the changes (If any) -

Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

Summary by CodeRabbit

• Chores
  • CI configuration updated to trigger builds on both the main and an additional tauri-ci branch.
  • Build workflow updated to use a different Tauri action version for the app build step.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[netlify]

✅ Deploy Preview for circuitverse ready!

Name	Link
🔨 Latest commit	3a9904a
🔍 Latest deploy log	https://app.netlify.com/projects/circuitverse/deploys/695a9c11f940cb00081e658f
😎 Deploy Preview	https://deploy-preview-715--circuitverse.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 43 (🔴 down 1 from production) Accessibility: 73 (no change from production) Best Practices: 92 (no change from production) SEO: 82 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Warning

Rate limit exceeded

@tachyons has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 6 minutes and 30 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between b300356 and 3a9904a.

📒 Files selected for processing (1)

• .github/workflows/tauri-release.yml

Walkthrough

The pull request updates .github/workflows/tauri-release.yml to add the tauri-ci branch to the push.branches triggers (in addition to main) and changes the Build Tauri App step to use tauri-action@v0 instead of tauri-action@v1. No other workflow logic or public API declarations are modified.

Possibly related PRs

• CI: Establishing an Automated Release Pipeline for Streamlined Deployment #503: Modifies the same workflow file—introduces/establishes the tauri-release workflow and its build steps.

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Fix Tauri CI' is vague and generic, lacking specificity about what aspect of Tauri CI was fixed or what changes were made.	Provide a more descriptive title that explains the specific fix, such as 'Update Tauri GitHub Action to v0 and add tauri-ci branch to workflow triggers' or similar.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/tauri-release.yml (1)

5-5: Clarify the intent of running a release workflow on a CI branch.

Running this release workflow on every push to "tauri-ci" will create draft releases and trigger builds across 4 platform configurations. Consider the following concerns:

• Operational cost: Each push triggers expensive multi-platform builds (macOS ARM, macOS Intel, Ubuntu, Windows), consuming significant CI minutes.
• Draft release clutter: Every push creates a new draft release with a version tag, which could accumulate and clutter the releases page.
• Tag conflicts: If __VERSION__ doesn't change between pushes, tag creation might conflict.

Recommended alternatives for CI testing:

1. Create a separate workflow (e.g., tauri-test.yml) that builds without creating releases
2. Add workflow_dispatch trigger for manual testing when needed
3. Use pull_request triggers to test builds before merging

If the goal is to test the release process itself, consider using workflow_dispatch with input parameters instead of a dedicated branch.

Could you clarify the specific use case for triggering releases on the "tauri-ci" branch?

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5e888c5 and 4ca6650.

📒 Files selected for processing (1)

• .github/workflows/tauri-release.yml