[Feature] Switch auto-update back to GitHub with canary pre-releases

[zerob13]

What do you need? / 你需要什么？

Summary

Switch the DeepChat auto-update mechanism back to using GitHub Releases as the update provider, and introduce a simple channel model where canary builds come from pre-releases and stable builds only track published releases.

Motivation

• GitHub Releases already provides a first-class notion of releases vs pre-releases, which maps well to a canary (pre-release) vs stable (release) update channel.
• electron-updater has built-in support for GitHub Releases as a provider, including reading release metadata and assets from the repository's tagged releases.
• Reference: https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
• Reference: https://www.electron.build/auto-update.html

Desired behavior

• When the app is in "canary" mode, the auto-updater should detect and offer updates from GitHub pre-releases (e.g. tagged canary builds or "Pre-release" marked versions).
• When the app is in "stable" mode, the auto-updater should ignore pre-releases and only detect updates from normal GitHub releases.
• Existing versioning stays semver-based (e.g. x.y.z, x.y.z-canary.n), and update checks use electron-updater's standard latest.yml / GitHub metadata flow without custom feed URLs.

Implementation notes

• Use electron-updater with the GitHub provider configuration so that release metadata and assets are published as GitHub Releases artifacts in CI.
• Configure CI to upload the built artifacts and metadata (latest.yml, platform-specific files) to the correct GitHub release or pre-release, instead of a custom/generic update server.
• Add an internal "update channel" setting (e.g. updateChannel = "stable" | "canary") that controls whether the app considers GitHub pre-releases or only full releases when calling autoUpdater.checkForUpdatesAndNotify().

Acceptance criteria

• Stable users only see updates when a new GitHub Release (not marked as pre-release) is published with valid update assets for their platform.
• Canary users can receive updates from GitHub pre-releases, and the app correctly differentiates between canary and stable versions when checking for updates.
• No manual feed URL management is required in the app code; configuration is driven via electron-builder / electron-updater publish settings and GitHub Releases.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• [Feature] Add ACP Support #1100

🔗 Related PRs

#604 - fix: fix autoCheck dialog [merged]
#840 - feat: support canary upgrade [merged]
#876 - fix: upgrade reboot failed [merged]
#1084 - fix: update tag_name for release artifact urls [merged]

👤 Suggested Assignees

• zerob13
• zhangmo8
• chenrui333

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Coding Plan

Approach

Ticket Summary

Switch DeepChat's auto-update mechanism from a generic CDN provider to GitHub Releases, implementing a channel-based model where canary builds use GitHub pre-releases and stable builds use normal releases, leveraging electron-updater's built-in GitHub provider support.

Observations

Codebase Summary

DeepChat is an Electron application (v0.5.5) that uses electron-updater with a presenter pattern for managing updates, settings, and application state. The application currently uses a generic CDN provider at https://cdn.deepchatai.cn/upgrade/ for updates and has existing support for 'stable' and 'canary' update channels stored in ElectronStore via ConfigPresenter. The build system uses electron-builder with platform-specific configurations (electron-builder.yml and electron-builder-macx64.yml) and GitHub Actions workflows for building, releasing, and deploying. Version management is strict semver (X.Y.Z) handled by build/generate-version-files.mjs. The GitHub repository is https://github.com/ThinkInAIXYZ/deepchat.

Assumptions

Assumption 1: Handling CDN-based deployments for canary builds

Options Considered:

• Keep deploy_canary.yml for backward compatibility or alternative distribution
• Remove deploy_canary.yml entirely since GitHub Releases handles all distributions
• Modify it to deploy only supplementary assets (non-update artifacts)

Chosen Option: Keep the existing deploy_canary.yml workflow as-is for now to maintain backward compatibility and avoid disrupting any existing distribution channels. The implementation will focus on adding GitHub Releases as the primary update mechanism. Teams can evaluate and remove the CDN deployment in a future iteration if no longer needed.

Rationale: Keep the existing deploy_canary.yml workflow as-is for now to maintain backward compatibility and avoid disrupting any existing distribution channels. The implementation will focus on adding GitHub Releases as the primary update mechanism. Teams can evaluate and remove the CDN deployment in a future iteration if no longer needed.

Assumption 2: Version format for canary builds

Options Considered:

• Update the version script to support prerelease tags like 1.0.0-canary.1
• Keep strict X.Y.Z versioning and rely solely on GitHub's prerelease flag for differentiation
• Use a hybrid approach with optional prerelease tag support

Chosen Option: Update generate-version-files.mjs to support optional prerelease tags in the format X.Y.Z or X.Y.Z-prerelease.N.

Rationale: This aligns with electron-updater's behavior where allowPrerelease defaults to true if the application version contains prerelease components like 0.12.1-alpha.1, providing clearer version semantics and better alignment with the ticket's desired semver-based versioning approach.

Assumption 3: Removal of custom manual update fallback

Options Considered:

• Remove the manual fallback entirely since GitHub provider is more reliable
• Keep the fallback for resilience
• Simplify the fallback to only handle edge cases

Chosen Option: Remove the custom manual update fallback logic.

Rationale: GitHub Releases is a supported provider out of the box and electron-updater with GitHub provider should be reliable enough without requiring custom fallback mechanisms. This simplifies the codebase and aligns with the ticket's goal of "no manual feed URL management."

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: electron-builder and Package Configuration

Configure electron-builder to use GitHub as the update provider and ensure package.json has proper repository metadata for auto-detection.

Task 1: Add Repository Field to package.json

Update package.json to include the repository configuration that electron-builder uses to auto-detect the GitHub provider.

• Add repository field with type "git" and url "https://github.com/ThinkInAIXYZ/deepchat.git"
• This enables electron-builder to automatically resolve the GitHub owner/repo for the update provider

Task 2: Configure GitHub Provider in electron-builder.yml

Replace the generic CDN provider with GitHub provider configuration in the main electron-builder configuration.

• Change the publish provider from "generic" to "github" in electron-builder.yml
• Remove or comment out the custom CDN url configuration
• Let electron-builder auto-detect owner and repo from package.json repository field
• Ensure the publish configuration is properly structured for GitHub Releases

Task 3: Configure GitHub Provider in electron-builder-macx64.yml

Apply the same GitHub provider changes to the macOS x64-specific build configuration.

• Update electron-builder-macx64.yml with "github" provider matching electron-builder.yml
• Remove generic CDN url to maintain consistency across build configurations

🤖 Prompt for AI agents

Configure electron-builder to use GitHub Releases as the update provider instead
of the generic CDN.

In package.json:
- Add repository field with type "git" and url
"https://github.com/ThinkInAIXYZ/deepchat.git"

In electron-builder.yml:
- Change publish provider from "generic" to "github"
- Remove the custom CDN url configuration
- Let electron-builder auto-detect owner/repo from package.json

In electron-builder-macx64.yml:
- Update publish provider to "github" matching electron-builder.yml
- Remove generic CDN url for consistency

Phase 2: Update Presenter Logic Modification

Modify the upgrade presenter to use electron-updater's native GitHub provider support with the allowPrerelease setting instead of manual feed URL management.

Task 1: Remove Manual Feed URL Construction

Simplify the upgrade presenter by removing custom CDN URL construction and feed URL management logic.

• In src/main/presenter/upgradePresenter/index.ts, remove the manual version URL construction that builds https://cdn.deepchatai.cn/upgrade/{channel}/{platform}.json
• Remove the autoUpdater.setFeedURL() calls since electron-updater will use the publish configuration from electron-builder
• Remove or simplify the sanitization logic for channels and platform strings that was specific to CDN URLs
• Remove cache-busting timestamp logic since GitHub API handles freshness

Task 2: Implement allowPrerelease Channel Control

Configure electron-updater's allowPrerelease property based on the user's update channel preference to enable canary/stable distinction.

• In src/main/presenter/upgradePresenter/index.ts, read the update channel from ConfigPresenter
• Set autoUpdater.allowPrerelease based on channel: true for 'canary', false for 'stable'
• Place this configuration in the initialization section alongside existing autoDownload and allowDowngrade settings
• Ensure allowPrerelease is set before calling checkForUpdates()

Task 3: Simplify Update Check Flow

Streamline the checkForUpdates method to use electron-updater's native GitHub provider flow without custom fallback logic.

• Replace manual axios-based fallback with standard autoUpdater.checkForUpdates() call
• Remove custom version comparison and GitHub URL construction logic
• Rely on electron-updater's built-in error handling and retry mechanisms
• Keep existing event handlers (update-available, update-not-available, error, etc.) since they work with any provider

🤖 Prompt for AI agents

Refactor upgradePresenter to use electron-updater's native GitHub provider
without manual feed URL management.

In src/main/presenter/upgradePresenter/index.ts:
- Remove manual CDN URL construction
(`https://cdn.deepchatai.cn/upgrade/{channel}/{platform}.json`)
- Remove `autoUpdater.setFeedURL()` calls
- Remove channel/platform sanitization logic specific to CDN
- Remove cache-busting timestamp logic

- Read update channel from ConfigPresenter
- Set `autoUpdater.allowPrerelease = true` for 'canary' channel, `false` for
'stable'
- Configure allowPrerelease in initialization before calling checkForUpdates()

- Remove axios-based manual fallback logic
- Remove custom version comparison and GitHub URL construction
- Use standard `autoUpdater.checkForUpdates()` with electron-updater's error
handling
- Keep existing event handlers (update-available, update-not-available, error,
etc.)

Phase 3: Version Format and Build Script Updates

Update version generation scripts to support semver prerelease tags for canary builds.

Update Version Generation Script

Modify build/generate-version-files.mjs to accept and validate semver prerelease formats.

• Update the version validation regex from /^\d+\.\d+\.\d+$/ to support optional prerelease tags: /^\d+\.\d+\.\d+(-[a-zA-Z0-9.-]+)?$/
• Ensure the script properly handles versions like "1.0.0-canary.1" when generating platform-specific metadata files
• Maintain backward compatibility with strict X.Y.Z format for stable releases

🤖 Prompt for AI agents

Update version generation script to support semver prerelease tags for canary
builds.

In build/generate-version-files.mjs:
- Update version validation regex from `/^\d+\.\d+\.\d+$/` to
`/^\d+\.\d+\.\d+(-[a-zA-Z0-9.-]+)?$/`
- Ensure proper handling of versions like "1.0.0-canary.1" when generating
platform metadata files
- Maintain backward compatibility with X.Y.Z format for stable releases

Phase 4: CI/CD Workflow Updates

Modify GitHub Actions workflows to properly publish update artifacts and metadata to GitHub Releases.

Task 1: Update Release Workflow for Update Artifacts

Ensure the release.yml workflow publishes all necessary update metadata files that electron-updater expects.

• In .github/workflows/release.yml, verify that electron-builder generates latest.yml, latest-mac.yml, and latest-linux.yml files during the build phase
• Ensure these metadata files are included in the artifacts uploaded to GitHub Releases alongside the platform installers
• Confirm that the prerelease input parameter correctly marks GitHub Releases as pre-release when creating canary builds
• Add a step or verification that all required update assets (installers + metadata) are present before release creation

Task 2: Document Canary Release Process

Update or create documentation for the new canary release workflow using GitHub pre-releases.

• Document that canary builds should be published with the prerelease flag set to true in release.yml
• Specify that canary versions should use prerelease tag format (e.g., 1.0.0-canary.1, 1.0.0-canary.2)
• Document that stable releases should use standard X.Y.Z versioning with prerelease flag set to false
• This can be added as comments in release.yml or as a separate documentation file in .github/ or docs/

🤖 Prompt for AI agents

Update GitHub Actions workflows to publish update artifacts and metadata to
GitHub Releases.

In .github/workflows/release.yml:
- Verify electron-builder generates latest.yml, latest-mac.yml, and
latest-linux.yml during build
- Ensure metadata files are uploaded to GitHub Releases with platform installers
- Confirm prerelease input parameter correctly marks releases as pre-release for
canary builds
- Add verification step that all required assets (installers + metadata) are
present before release creation

Document canary release process:
- Add documentation (comments in release.yml or separate doc in .github/ or
docs/)
- Document prerelease flag should be true for canary builds
- Specify canary versions use format like 1.0.0-canary.1
- Document stable releases use X.Y.Z format with prerelease flag false

Phase 5: Configuration Management

Ensure the existing update channel preference system properly integrates with the new GitHub provider implementation.

Task 1: Verify Update Channel Settings

Confirm that the existing ConfigPresenter update channel management works correctly with the new implementation.

• In src/main/presenter/configPresenter/index.ts, verify that getUpdateChannel() and setUpdateChannel() methods are working correctly
• Ensure the default channel remains 'stable' as currently configured
• Confirm that IAppSettings includes updateChannel in its type definition
• Verify ElectronStore properly persists channel preferences across app restarts

Task 2: Add Transition Handling (Optional)

Consider adding logic to handle users transitioning from the CDN-based update system to GitHub Releases.

• Evaluate whether existing users on older versions need any special migration handling
• If the current app version can't detect GitHub-based updates, consider a transitional approach (this may not be necessary if the version format remains compatible)
• Document any version compatibility considerations for the development team

🤖 Prompt for AI agents

Verify and integrate existing update channel configuration with the new GitHub
provider implementation.

In src/main/presenter/configPresenter/index.ts:
- Verify getUpdateChannel() and setUpdateChannel() methods work correctly
- Ensure default channel remains 'stable'
- Confirm IAppSettings type includes updateChannel
- Verify ElectronStore persists channel preferences across restarts

Optional transition handling:
- Evaluate if users on older versions need migration handling for CDN-to-GitHub
transition
- Consider transitional approach if version format compatibility is an issue
- Document version compatibility considerations for the team

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Configure electron-builder to use GitHub Releases as the update provider instead
of the generic CDN.

In package.json:
- Add repository field with type "git" and url
"https://github.com/ThinkInAIXYZ/deepchat.git"

In electron-builder.yml:
- Change publish provider from "generic" to "github"
- Remove the custom CDN url configuration
- Let electron-builder auto-detect owner/repo from package.json

In electron-builder-macx64.yml:
- Update publish provider to "github" matching electron-builder.yml
- Remove generic CDN url for consistency
===============================================================================

Task: 2

Refactor upgradePresenter to use electron-updater's native GitHub provider
without manual feed URL management.

In src/main/presenter/upgradePresenter/index.ts:
- Remove manual CDN URL construction
(`https://cdn.deepchatai.cn/upgrade/{channel}/{platform}.json`)
- Remove `autoUpdater.setFeedURL()` calls
- Remove channel/platform sanitization logic specific to CDN
- Remove cache-busting timestamp logic

- Read update channel from ConfigPresenter
- Set `autoUpdater.allowPrerelease = true` for 'canary' channel, `false` for
'stable'
- Configure allowPrerelease in initialization before calling checkForUpdates()

- Remove axios-based manual fallback logic
- Remove custom version comparison and GitHub URL construction
- Use standard `autoUpdater.checkForUpdates()` with electron-updater's error
handling
- Keep existing event handlers (update-available, update-not-available, error,
etc.)
===============================================================================

Task: 3

Update version generation script to support semver prerelease tags for canary
builds.

In build/generate-version-files.mjs:
- Update version validation regex from `/^\d+\.\d+\.\d+$/` to
`/^\d+\.\d+\.\d+(-[a-zA-Z0-9.-]+)?$/`
- Ensure proper handling of versions like "1.0.0-canary.1" when generating
platform metadata files
- Maintain backward compatibility with X.Y.Z format for stable releases
===============================================================================

Task: 4

Update GitHub Actions workflows to publish update artifacts and metadata to
GitHub Releases.

In .github/workflows/release.yml:
- Verify electron-builder generates latest.yml, latest-mac.yml, and
latest-linux.yml during build
- Ensure metadata files are uploaded to GitHub Releases with platform installers
- Confirm prerelease input parameter correctly marks releases as pre-release for
canary builds
- Add verification step that all required assets (installers + metadata) are
present before release creation

Document canary release process:
- Add documentation (comments in release.yml or separate doc in .github/ or
docs/)
- Document prerelease flag should be true for canary builds
- Specify canary versions use format like 1.0.0-canary.1
- Document stable releases use X.Y.Z format with prerelease flag false
===============================================================================

Task: 5

Verify and integrate existing update channel configuration with the new GitHub
provider implementation.

In src/main/presenter/configPresenter/index.ts:
- Verify getUpdateChannel() and setUpdateChannel() methods work correctly
- Ensure default channel remains 'stable'
- Confirm IAppSettings type includes updateChannel
- Verify ElectronStore persists channel preferences across restarts

Optional transition handling:
- Evaluate if users on older versions need migration handling for CDN-to-GitHub
transition
- Consider transitional approach if version format compatibility is an issue
- Document version compatibility considerations for the team

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord or schedule a call!