search

nchapman / pulsar

Mozilla Public License 2.0
1 stars 1 forks source link

Add automatic updates #12

Open nchapman opened 5 months ago

nchapman commented 5 months ago

https://tauri.app/v1/guides/distribution/updater

ospfranco commented 4 months ago

Should I take care of this?

nchapman commented 4 months ago

@ospfranco yes please! Let me know what you think we should do about hosting the update manifest.

ospfranco commented 4 months ago

As for hosting the Manifest: I guess we can just use github right? I do the same for Sol. They just need a public URL.

Regarding generating the keys, I guess you want to take care of this and keep them somewhere safe? You can then later, upload them encrypted into the repo secrets and we will then use them to sign the package on CI.

nchapman commented 4 months ago

GitHub would usually be fine. The only problem for us is that we're going to move the repo to a different org which will break the URL. Not sure what to do about that.

Regarding the keys, I went ahead and generated them. I added the pubkey into a branch and added the private key as a secret on the repo. You can take it from here! Let me know if I need to put the private key anywhere else.

https://github.com/nchapman/pulsar/pull/61

ospfranco commented 4 months ago

Without the name or the next domain available I don't see any solution then. We can just release the app as beta versions and once a rebrand happens then add a Download link to a new app version?

nchapman commented 4 months ago

What if we just use a Gist for now? Then we can just update the manifest location in a future update and have it point to the new repo.

ospfranco commented 4 months ago

From what I'm reading it doesn't make much of a difference right? The manifest only needs to be there. After each update, the tauri.conf.json will be updated in the process. So the last release that will be in the manifest will be a middle update that can then be later updated to future versions. A gist is kinda fragile, I would rather have the manifest automatically updated and committed via ci/scripts.

nchapman commented 4 months ago

Yeah I agree that the gist is fragile in that it's not easily automated. We will have the problem where we will have a version that points to the old repo that can't discover updates in the new one. What if we push the manifest to S3 instead?

ospfranco commented 4 months ago

I think I didn't get my point across. I think it shouldn't be a problem as long as we add one last entry with an update to the latest version with a new url. Here is an illustration:

Image

Old clients will update to version 0.3 (just an example). That version itself will point to an updated manifest, meaning once open, it will update to the further versions. So 0.3 will be a stop-gap update for users still using Pulsar at EOL.

nchapman commented 4 months ago

I think this would work as long as GitHub correctly redirects to the new repo location. Otherwise when 0.2 goes to check for updates, the repo will have already moved and it won't be able to find that file. GitHub generally tends to handle redirects for moved repos quite well. I don't know if that extends to all URLs like raw.githubusercontent.com.

ospfranco commented 4 months ago

S3 is a bit unwieldy. At that point I prefer a gist tbh.

ospfranco commented 3 months ago

Just for documentation purposes. We decided to go with a r2 bucket. Gists are not updatable via command line (only via github cli and https authentication, which is too much work). Secrets are configured on this repo and there will be a script soon that updates the manifest and uploads it again to the r2 bucket.