search

daisy / pipeline-ui

A user interface for the DAISY Pipeline 2
MIT License
6 stars 2 forks source link

Publish nightly builds #142

Open bertfrees opened 1 year ago

bertfrees commented 1 year ago

We could modify the Github workflow to build on every commit and attach the build artifacts to a special release tagged "snapshot". But first we need to get the build working again.

GeorgeKerscher commented 1 year ago

Would this much like the Thorium nightly builds? That has been working for me.

bertfrees commented 1 year ago

Yes, it seems to be much like Thorium.

Link to Github releases page: https://github.com/edrlab/thorium-reader/releases

danielweck commented 1 year ago

Hello, Thorium's continuous release technique is quite rudimentary / wonky, because although it is now powered by a GitHub Actions Workflow, it was originally implemented for Travis and AppVeyor. You know the adage "if it ain't broke ... don't fix it" (wink)

Basically, an external Javascript invokes GitHub's HTTP REST APIs via the Octokit NodeJS lib (see links below). The difficult part was to remove existing release tags and associated uploaded assets. This phase sometimes still fails (not sure why), resulting in dangling release drafts in the GitHub page (thankfully, only admins/developers see this, not end-users).

With our technique, old builds are replaced, we do not provide a build archive. Basically, we only provide a build of the latest HEAD of the develop branch. This may not be desirable in your case (i.e. you might want to be able to test previous automated nightly builds, to match an end-user experience).

Links:

https://github.com/edrlab/thorium-reader/blob/4e62aeca5a231a68b7940d17b62a0c656eeabf52/.github/workflows/main.yml#L114 ==> https://github.com/edrlab/thorium-reader/blob/develop/scripts/release-github.js

bertfrees commented 1 year ago

@danielweck Thanks. This is exactly what I had in mind, and what we also do for Liblouis. (We don't remove tags though.) I'm not interested in going back to older builds.