search

loft-sh / devpod

Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker.
https://devpod.sh
Mozilla Public License 2.0
8.43k stars 307 forks source link

Allow user to opt into pre release updates #1017

Open shanman190 opened 2 months ago

shanman190 commented 2 months ago

Is your feature request related to a problem? No, it's not.

Which solution do you suggest?
Add a configuration parameter to allow the user to opt into pre release versions.

Which alternative solutions exist?
Manually upgrade by watching the releases directly.

Additional context

pascalbreuninger commented 2 months ago

@shanman190 thanks for the suggestion. It's definitely a good addition and we've looked into it a while ago. The problem is that I haven't found a solid way of implementing it without a custom update server. It's not that much effort but more than it's probably worth for the few people actually using prerelease versions.

To future readers: If you always want to stay on the bleeding edge please upvote this issue

shanman190 commented 2 months ago

@pascalbreuninger, that's fair.

When I was glancing through it seemed like a user setting that goes into ~/.devpod/config.yaml could be the start of the chain (this could additionally be exposed via the UI). Then when the UI is asking for the releases from the rust API server, it could send over a query parameter indicating a configured user preference or no query parameter at all if not configured (none (disabled), includePrerelease=true (enabled), or includePrerelease=false (disabled)). Then down in https://github.com/loft-sh/devpod/blob/main/desktop%2Fsrc-tauri%2Fsrc%2Fupdates.rs#L233-L238 if the option came over as explicitly as includePrerelease=true, then we'd just include or exclude them as necessary.

pascalbreuninger commented 2 months ago

@shanman190 I see where you're going and it would make sense but that part is only for the releases display in the UI. The real update checks are handled by tauri and we just point them to the latest github releases: https://github.com/loft-sh/devpod/blob/0b13c24f407078fd1ddcbe3690bd3d88a86464b6/desktop/src-tauri/tauri.conf.json#L109

As we're discussing I've stumbled over this issue over in the tauri repo. We could probably change the endpoint based on a context option like you suggested, restart the app and have it look for new updates via a prerelease URL.

Two uncertainties from my side:

  1. Is there a URL in github to always resolve to the latest prerelease?
  2. Without a custom update server there's no nice way of downgrading, it'll be a manual process again
shanman190 commented 2 months ago

@pascalbreuninger, ahh, I see. From a GitHub API standpoint, you'd have to list all releases and filter them as there isn't an endpoint to acquire the latest prerelease generically like there is for the latest stable release.