[FeatureRequest] Integrate appcast generation with GitHub Releases / Pages

[k06a]

My app binaries are hosted on GitHub Releases page. I just wanna Sparkle to check this page for new versions :)

[zorgiepoo]

It may be more practical to generate an appcast server-side based on changes to GitHub's release page. I don't really know how much info GitHub gives you in order to do that in a sane manner however.

[kainjow]

You could subscribe to the Atom page and update your Sparkle version once a new release comes out. Probably the safest way.

https://github.com/sparkle-project/Sparkle/releases.atom

[zorgiepoo]

Briefly looking at the atom feed, it's not meant to be used for this kind of task. Probably you'd want GitHub's Releases API.

[kainjow]

Well I meant doing it manually, no automation, since you would want to probably wait for a release to update in case there are bugs, especially if you're about to ship your software.

[zorgiepoo]

Don't see the point of subscribing to the feed if you are the one pushing the release onto GitHub and have to generate the appcast manually. Anycase, I thought the original poster wanted it to be automated. One could try to make use of the "pre-release" field GitHub has, too.

[k06a]

Really I would like to setup update suggestion for my app without any own backend. Don't wanna care of this dependency never. Just wanna add binaries to GitHub Releases page.

[kornelski]

That sounds like a very convenient thing indeed.

I do have some concerns:

• Supporting GitHub's releases page directly would require Sparkle using GitHub API directly. That's a very specific dependency for Sparkle, and although GitHub is great and all, it is a dependency on a non-standard API of a closed-source proprietary product.
• Without an appcast there are no DSA signatures available, so we'd need to figure out what level of security we want, and how to implement it.

How about a slightly different thing:

a tool that generates appcast.xml file from a GitHub's releases page? (and maybe even a local directory containing binaries)

[k06a]

@pornel do you mean include appcast.xml in git repository files? I think it can be done, by filling template and appending to xml file or add terminal tool to add versions to appcast.xml.

[uranusjr]

While most information can be built automatically, the GitHub release page do lack some information essential for the appcast file, e.g. the version string (that positive incremental integer thing). Some extra metadata would still be needed.

[kornelski]

@k06a Yes, something like that. Committed to the repo, or perhaps to gh-pages?

So it may be possible to do that with a tool that:

1. Assumes it's run in a .git clone from github, so git remote -v will let you guess URL of the github releases page
2. Finds the releases
3. Downloads the releases (?) to sign them with a private DSA key
4. Generates appcast.xml
5. Commits appcast.xml to gh-pages of the project (which must match appcast URL in Info.plist)

So that would be possible to do as a standalone tool outside of Sparkle, and the whole operation could be done with just one command.

[k06a]

Maybe called like this:

ruby release_appcast.rb appcast.xml https://github.com/sparkle-project/Sparkle/releases/download/1.12.0a2/Sparkle-1.12.0a2.tar.bz2
git commit -m "Released new version"
git push

Or git commands can be included inside script.

[huangyq23]

I have a similar attempt recently.

With some scripting and naming conventions. it is possible to encode the version number into the binary archive's filename.

I had a script to perform archive and export the app zip file with names like MyApp.v1.2.b20151011.zip. Here, 1.2 and 20151011 maps to CFBundleShortVersionString and CFBundleVersion extracted from Info.plist.

With that, I can draft up and publish the releases and upload the binary just as usual in github web interface.

Then there is the matter of setting up the gh-pages correctly to generate the appcast.xml. Since github already have all the releases objects supplied into the rendering context as site metadata, it is possible to build the entire xml within the Jekyll process using Liquid.

I filter out all draft and pre-releases for my appcast.xml. I also have a separate appcast_pre.xml that includes pre-releases for my alpha/beta channel.

The biggest benefit of render the xml in Github is no extra interaction with the Github Release API is required; normal git access will suffice. Obviously this is strong convention and less flexible since the resolving logic relies on the filename, but it suits my objectives well.

I can share my build script and liquid template for appcast.xml if anyone is interested.

[k06a]

@huangyq23 will be perfect to share you result with community! 👍

[huangyq23]

@k06a Just got some time to work on this. I have them uploaded to a gist.

I also wrote a blogpost explaining some of the thought behind the solution.

Hope it helps.

[kornelski]

@huangyq23 That's great! Thank you very much

[orta]

The CocoaPods app uses the same kind of technique as @huangyq23 mentioned, incase you want more examples. See the bottom of the Rakefile

[pierredavidbelanger]

As a lazy person, I do not want to have to maintain appcast.xml after each release. So, I just made a project to solve this exact problem for myself. Then I realised it may help someone else on this thread.

[lwouis]

If someone is interested in a lightweight solution that doesn't require a backend (i.e. only using github to host the releases and appcast.xml), you can take a look at my working approach here. I'm generating an <item> in appcast.xml during a new release using 30 lines of bash.

It is tested, and works. It delivers updates without the need for an extra web-server.

[noah-nuebling]

See my solution here.

It's a little verbose and slow, but it has these perks:

• It doesn't require a backend
• It creates a separate appcast for prereleases
• It automatically generates update notes from the GH Releases' body text. They look nice and native and support darkmode.
• It's mostly written in python and I documented it pretty well, so you should be able to adapt it to your needs without too much trouble
• It canalso record and plot downloads counts
• You could probably even use GitHub actions to run this whenever you create a new release, but I haven't looked into that.

Thanks @lwouis for the inspiration!