Github downloads are horribly slow and unreliable

[peabee]

Frustration........
Release .zips are humongous and take forever to download and then frequently refuse to open......
Maybe release artefacts could be individual files rather than combined in huge .zip??

[dimkr]

When build artifacts (*.iso and *.sfs) are uploaded, they're automatically joined into a single .zip file. Wildcards are convenient, because some file names change (for example, the kernel sources SFS name) and different build configurations produce different sets of files (for example, some don't produce devx or docx).

It is possible to upload the build artifacts separately, one-by-one, but somebody needs to write the logic that checks if a file exists, for every possible output file (kernel sources, devx, docx, nlsx, ISO, ...) and handle every possible corner case (for example, some ISO images have a -docx-nlsx.iso suffix).

[lakshayrohila]

Frustration........ Release .zips are humongous and take forever to download and then frequently refuse to open...... Maybe release artefacts could be individual files rather than combined in huge .zip??

Currently the user can click the Upload Release checkbox while running the github action. All the files then would be non-merged + SHA512 checksum file will also be provided. The release hence generated would be a draft. Then, if you're unsatisfied with the result, you can delete the draft release.

[dimkr]

And don't forget that builds artifacts are not supposed to be user-friendly, they're supposed to be machine-friendly. This .zip file simplifies release.yml, which downloads a single file (the .zip file) and creates a release with all files inside it.

[peabee]

Currently the user can click the Upload Release checkbox while running the github action.

Thanks.

[lakshayrohila]

I have modified the "Building Puppy On Github" wiki page to allow the users to understand more about when to check upload release button and when not to. Here is the comparison.

[dimkr]

The wording is inaccurate. I implemented the draft release checkbox because unlike draft releases, build artifacts are deleted automatically after a day, making it more convenient to leave it unchecked if it's a build you want to download yourself but don't intend to publish in a release. And if you do want to publish a new release, you can enable this option, download the draft release, test it, then publish the release or discard it if it's not ready for release. 90% of users of this action would want to download the build output, but I wouldn't recommend using this option unless you really intend to publish a release, because it's easy to forget a draft release behind and waste space.