Hello, I experimented a bit more with the process by creating a release on my own YaCy fork (Release_1.91.9411-alpha
). The process is really simple, and as you can see the release include the usual sources packages but also the tar.gz and debian binary files I added. The most problematic part would finally to have MS Windows, Mac OS and Linux build machines if we would like to include binaries for these platforms and not only a cross platform standard tar.gz or zip.
So what about releasing minor versions of YaCy binary builds on a more regular basis?
I also tested if the release page could be used as an alternative update location, by adding a
- Code: Alles auswählen
network.unit.update.location3 = http://github.com/luccioman/yacy_search_server/releases
line in the defaults/yacy.network.freeworl.unit of a 1.90 peer. YaCy updater effectively find my alpha release... but unfortunately, with 1.90 and also with latest current code it doesn't work. Worse, it seems to work but indeed fails and lets YaCy in a state where it can no more boot. The root cause is that for some reason, downloading the release with a browser works, but YaCy updater is rejected : GitHub redirects to Amazon S3 (correctly handled by YaCy HTTPClient), but then returns a HTTP 403 status.
The next steps to fix are the following :
- HTTP 403 status is ignored and YaCy creates a DATA/RELEASE/...tar.gz file containing the HTTP message
- The install button is then enabled : when launching the install process, tar.gz extraction failure is ignored and the update script is launched, deleting all the YaCY lib/*.jar files, then preventing any restart...
To conclude, using the GitHub release page as an alternative update location looks promising, but some work is still needed