feat: migrate to bun in github workflows

[sankhavaramsaitulasiram]

Description

Types of changes

What types of changes does your code introduce?

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Other (please describe):

Further comments (optional)

Summary by CodeRabbit

• Chores
  • CI/CD pipelines switched from Node.js to Bun: workflows now install Bun and use Bun-based commands for installing dependencies, building, and extracting package versions. Continuous integration behavior remains unchanged for end users.

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

[coderabbitai]

Walkthrough

CI workflows replace Node.js/npm with Bun: install Bun via oven-sh/setup-bun@v2, run bun install and bun run build (with a config copy step in one workflow), and retrieve package versions using bun run -e "console.log(require(...).version)" instead of Node's -p.

Changes

Cohort / File(s)	Summary
Check-package workflow \.github/workflows/check-package-version.yml	Replaced Node.js setup with oven-sh/setup-bun@v2 (pinned to bun-version: 1.0.1), added cp config.json.default config.json, replaced npm install && npm run build with bun install && bun run build.
Release workflows (multiple jobs) \.github/workflows/release.yml	Added Bun setup (oven-sh/setup-bun@v2, bun-version: 1.0.1) in build_frontend, build_admin_frontend, and build_backend jobs and changed package-version extraction from node -p "require('.../package.json').version" to bun run -e "console.log(require('.../package.json').version)".

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Repetitive configuration edits across two workflow files.
• Review focus:
  • Bun setup placement and bun-version pin (1.0.1).
  • The added cp config.json.default config.json step and its path/context.
  • Quoting and correctness of bun run -e "console.log(require(...).version)" in each job.

Poem

🐇 I hopped through YAML, teeth so bright,

Swapped Node for Bun — a sprightly bite.
Builds now skip and swiftly run,
Carrots found in every CI sun. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is largely incomplete, containing only placeholder hyphens in required sections with no actual content or type classification selected.	Fill in the Description section with details about the migration, select 'Build related changes' in the Types of changes checklist, and add any relevant comments.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: migrate to bun in github workflows' clearly and accurately summarizes the main changes: replacing Node.js with Bun in GitHub Actions workflows.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/fix-ci-cd

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ea2b95b and 2815b5a.

📒 Files selected for processing (2)

• .github/workflows/check-package-version.yml (2 hunks)
• .github/workflows/release.yml (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Cloudflare Pages

🔇 Additional comments (1)

.github/workflows/check-package-version.yml (1)

14-17: Version pinning concern from previous review is now resolved.

The workflow correctly pins Bun to version 1.0.1 instead of using latest, which ensures CI reproducibility and deterministic behavior across runs. This addresses the major issue flagged in previous reviews.

---

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.}

[cloudflare-workers-and-pages]

Deploying arka with    Cloudflare Pages

Latest commit:	2815b5a
Status:	✅  Deploy successful!
Preview URL:	https://04826b9e.arka-3qg.pages.dev
Branch Preview URL:	https://feat-fix-ci-cd.arka-3qg.pages.dev

View logs

[coderabbitai]

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

.github/workflows/check-package-version.yml (2)

1-35: Improve PR description with migration scope and intent.

The PR description currently contains only placeholders. For a migration of this scope, please provide:

• Clear explanation of why Bun was chosen over npm
• List of all workflows being migrated
• Any breaking changes or required updates for developers (e.g., local setup instructions)
• Testing performed to validate Bun/npm compatibility
• Lock file strategy and any required .gitignore updates

Would you like me to help draft a comprehensive PR description that documents the migration scope, rationale, and validation steps?

---

1-35: Provide detailed PR description documenting migration scope and validation.

The PR description currently contains only placeholders, which makes it difficult to understand the context, rationale, and scope of this Bun migration across CI workflows.

Please update the PR description to include:

• Why Bun? Rationale for choosing Bun over npm (performance, features, etc.)
• Scope: List of all workflows being migrated as part of this PR and any future work
• Developer impact: Changes required for local development workflows and setup instructions
• Validation: Testing performed to confirm Bun/npm build compatibility
• Lock file strategy: Whether bun.lock should be committed or how it is managed
• Breaking changes: Any changes to CI behavior or artifact output

This context is essential for reviewers and future maintainers.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6150e29 and 30a872f.

📒 Files selected for processing (2)

• .github/workflows/check-package-version.yml (2 hunks)
• .github/workflows/release.yml (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Cloudflare Pages

🔇 Additional comments (2)

.github/workflows/check-package-version.yml (2)

30-31: This workflow step correctly aligns with the project's bun-native setup.

The backend is already a bun project (as evidenced by the engines field requiring "bun": >=1.0.0" and build scripts using bun build). The workflow change from npm to bun is the correct implementation, not a risky migration. The bun.lock file is committed to version control, ensuring reproducible builds across CI runs. No further action needed.

Likely an incorrect or invalid review comment.

---

30-31: This is a new workflow, not a migration from npm to Bun — the backend has always been Bun-native.

The original concern assumes a migration from npm to Bun, but commit 30a872f creates this workflow file for the first time (new file, not modified). The backend package.json has always specified bun build src/index.ts as the build script, not npm run build. The bun.lock file is properly committed to the repository, which is the standard practice for Bun projects (similar to how package-lock.json is committed for npm projects). The project explicitly requires Bun via "engines": { "bun": ">=1.0.0" }, and all npm scripts already use Bun commands (bun test, bun build, etc.). The workflow correctly runs the build that was already defined in package.json, so compatibility concerns do not apply here.