Updater and GitHub releases automation

[leet4tari]

Been task to setup an application built with tauri-apps to take advantage of the updater feature and ran into a few things that I hope I could get some clarification on and possible improve for others.

In the Updater docs, the Server Support points out the use of static JSON file for release info, suggesting S3 or GitHub gists, with an example of the Static JSON pointing to assets using urls in GitHub repo/releases. This is good, but be better if there was a working example that could be tested against. Might have made my life easier, unless I just missed it.

The part that I have a question about, is the TIP offered later, suggesting that Tauri Action, generates a static JSON file for you to use on CDNs such as GitHub Releases., really does not point out that the file latest.json and it's CDN location, like in S3 or GitHub gists needs to be added into the tauri.conf.json as a mostly static URL. This too could also be better and save some people some time.

My question, is it possible to add some logic, that could better leverage the GitHub releases without any secondary hosting endpoints?
An idea of the process, could be, if a GitHub releases URL is detected/used in the endpoint field, for example - https://github.com/leet4tari/tari-launchpad/releases, then an api request to the GitHub could be used to extract the release tagged with latest and download the useful latest.json file.

Bash test as an example ...

curl -s https://api.github.com/repos/leet4tari/tari-launchpad/releases/latest | jq '.assets[] | select( ."name" == "latest.json" ) | .browser_download_url'

Output of the above request as shown below, can be downloaded and used for the updating process

"https://github.com/leet4tari/tari-launchpad/releases/download/v0.1.1/latest.json"

Another thing that might be useful, would be if the tauri-action could override the endpoints with the local repo/owner and then pub key from envs/secrets, so that a forked repo would almost work without much merge and conflict resolving. I think some of this is possible with tauri build --config merge config and might be what I end up using, but could save other people some time.

[FabianLars]

Better documentation is something i'm actively working on for v2 (first iteration of the guide literally merged yesterday). Better examples for using github as a cdn were long planned for that.

My question, is it possible to add some logic, that could better leverage the GitHub releases without any secondary hosting endpoints?

No extra logic is required. Just use https://github.com/<user>/<repo>/releases/latest/download/latest.json as the endpoint url.

Another thing that might be useful, would be if the tauri-action could override the endpoints with the local repo/owner and then pub key from envs/secrets, so that a forked repo would almost work without much merge and conflict resolving. I think some of this is possible with tauri build --config merge config and might be what I end up using, but could save other people some time.

Hmm, probably won't be added tbh, i'd prefer the action to modify the app as least as possible.

Thanks for your feedback.

[leet4tari]

Thanks for you quick and helpful feedback @FabianLars .

Thanks for working on the docs, might I ask for a link to the PR to look over, pretty please?

I am sure I tested the github url, but my testing might have been flawed in some way. How about adding a note above the URL format some place useful and also, maybe even more useful, how to test or use the download URL, like curl -OJL https://github.com/leet4tari/tari-launchpad/releases/latest/download/latest.json or wget -c --content-disposition https://github.com/leet4tari/tari-launchpad/releases/latest/download/latest.json

Maybe I can rather ask, how would you suggest using the updater endpoint between repos and forks, without running into merge conflicts? I think I might be at a point where I have run out of ideas and some well used hint or process will spark some progress.

Thinking aloud, maybe a .env include that could be gitignored and force updated only when need and not on merge?

[FabianLars]

Thanks for working on the docs, might I ask for a link to the PR to look over, pretty please?

https://v2.tauri.app/distribute/pipelines/github/ / tauri-apps/tauri-docs#2313

How about adding a note above the URL format some place useful and also

Yes of course, that'll be part of it (can't really omit that in a guide about it).

how to test or use the download URL, like curl -OJL https://github.com/leet4tari/tari-launchpad/releases/latest/download/latest.json or wget -c --content-disposition https://github.com/leet4tari/tari-launchpad/releases/latest/download/latest.json

Not sure what you're trying to achieve with that tbh.

Maybe I can rather ask, how would you suggest using the updater endpoint between repos and forks, without running into merge conflicts?

I don't really get why'd you want that in the first place tbh, or maybe i don't understand what you're actually asking here.

In my experience those 2 lines don't really get in the way, but if you'd prefer not to have them in there, you can use the --config flag you already mentioned, which btw supports file paths and inline strings.

[leet4tari]

Thanks for working on the docs, might I ask for a link to the PR to look over, pretty please?
https://v2.tauri.app/distribute/pipelines/github/ / tauri-apps/tauri-docs#2313

Thanks, found a few very useful items I will put into place, thou will have to wait til we move to v2.

How about adding a note above the URL format some place useful and also
Yes of course, that'll be part of it (can't really omit that in a guide about it).

I see an example in the new docs. I think I found the wrong URL format in an old post, which was mainly why I opened this discussion.

how to test or use the download URL, like curl -OJL https://github.com/leet4tari/tari-launchpad/releases/latest/download/latest.json or wget -c --content-disposition https://github.com/leet4tari/tari-launchpad/releases/latest/download/latest.json
Not sure what you're trying to achieve with that tbh.

Trying to suggest offering a troubleshooting way to test the latest.json download for GitHub Releases with at least two different complete commands. This might have been where I went wrong trying the GitHub asset download, because curl and wget both don't follow redirects by default and I was not expecting a redirect, which I am thinking, other beginners might run into the same problem. Rather have a little more info, they expect every user to be advanced enough to know alot (for me felt like it was not working)

Reread my update, also has me thinking it might be a good idea to remind the user that pre-releases and drafts can't be marked as latests and would not become the next download for updater.

Maybe I can rather ask, how would you suggest using the updater endpoint between repos and forks, without running into merge conflicts?

I don't really get why'd you want that in the first place tbh, or maybe i don't understand what you're actually asking here.

In my experience those 2 lines don't really get in the way, but if you'd prefer not to have them in there, you can use the --config flag you already mentioned, which btw supports file paths and inline strings.

Mmm, maybe I misunderstood your suggestion, can I use https://github.com/<user>/<repo>/releases/latest/download/latest.json as is in my endpoint and builds in my fork and the parent repo will work correctly? ... or is the correct way providing different config files that is local to the repo? I did not see an example of the inline config and worried that I might commit my fork endpoint into the parent repo. The auto(magic) substitution would be awesome for lazy person like me, possible also avoid the human error too.

Thanks for all the feedback and effort.

[FabianLars]

Thanks, found a few very useful items I will put into place, thou will have to wait til we move to v2.

Well, if you have any hints (most of these docs are applicable to v1 too) i'd be open to any feedback :)

I see an example in the new docs. I think I found the wrong URL format in an old post, which was mainly why I opened this discussion.

👍

Trying to suggest offering a troubleshooting way to test the latest.json download for GitHub Releases with at least two different complete commands. This might have been where I went wrong trying the GitHub asset download, because curl and wget both don't follow redirects by default and I was not expecting a redirect, which I am thinking, other beginners might run into the same problem.

Okay, gotcha. I'll keep that in mind!

Rather have a little more info, they expect every user to be advanced enough to know alot (for me felt like it was not working)

This is indeed a general problem of our docs and something we're generally aware of - we'll keep this in mind in this context too, thanks!

Reread my update, also has me thinking it might be a good idea to remind the user that pre-releases and drafts can't be marked as latests and would not become the next download for updater.

Hmm yeah, good call. That also reminds me that i wanted to explain draft releases in general because i often get asked why there's no release after the workflow succeeded because drafts don't show on the repo main page / aren't visibile to non repo owners etc.

Mmm, maybe I misunderstood your suggestion, can I use https://github.com///releases/latest/download/latest.json as is in my endpoint and builds in my fork and the parent repo will work correctly?

Ah no, that was not a literal url. You'll still have to replace with the actual values.

or is the correct way providing different config files that is local to the repo?

yup

The auto(magic) substitution would be awesome for lazy person like me, possible also avoid the human error too.

Totally understand the sentiment but i'd say that we won't add this to tauri / the action. The feedback is noted though...

[leet4tari]

I think you have answered my big questions, thanks a ton!