GitHub workflow for generating test distributions (zips)
Builds of "FUSE" emulator with my own mods
Status: Beta
Brought to you by:
arki55
Menu
▾
▴
#13 GitHub workflow for generating test distributions (zips)
test
2024-02-03
2023-05-13
No
Modify GitHub build check files and implement
(A) Wokrflow for generation of distribution files (zips) for selected build configurations.
On Windows:
These generated zip files will contain all necessary DLLs (in case of Windows), including libspectrum.dll and once downloaded an unzipped, allow testing of features included in pull request for which it will generated.
On Linux: TBD - most probably done with later ticket
Will be executed manually on demand.
(B) Workflow for nightly build of master + automated pre release
- Makes use of the above workflow
- Is triggered automatically every night at 1 AM CET + can be triggered manually as well
- Has job that merges master from official Fuse (SourceForge) repo first
- If successful, generated release is automatically released, does not need manual released (is not a draft)
- last 5 releases are kept, older removed (in GitHub). Releases deletion is not synced to SourceForge yet.
Working branch:
https://github.com/arki55/fuse-fuse/tree/arki55/features/T13-github-distribution-workflow
Final version of changes:
https://github.com/arki55/fuse-fuse/tree/arki55/features/T13-github-distribution-workflow-final-2
Pull request into master (the same repo)
https://github.com/arki55/fuse-fuse/pull/39
Pull request into original Fuse repo:
https://sourceforge.net/p/fuse-emulator/fuse/merge-requests/25/
Last edit: Arki55 2023-08-10
Implementation finished. First demo test build release published and synced into SourceForge (arki55)
Windows win32 and windows SDL UI zipped builds available for download.
Last edit: Arki55 2023-07-11
Implemented second workflow: Nightly build
Triggered automatically each night at 1 AM (UTC) or manually Practically around 2AM CEST.
This workflow makes use of the TEST-BUILD workflow by providing specific arguments to it.
Description will be: Nightly master build
Before creation of pre-release, fresh master is merged from Fuse repository (Source Forge).
Created release is not draft, but immediately released (does not need manual releasing).
Example of such run:
https://github.com/arki55/fuse-fuse/actions/runs/5657641377
Generated files are synced into SourceForge under the address like:
https://sourceforge.net/projects/arki55-fuse-mod/files/test_arki55_master_2023-08-09--02-09-55/
Every night a new release is being generated and synced to SourceForge.
Only last 5 releases are kept (in GitHub). Older are deleted. Deletion in SourceForge does not work yet.
I've set arki55/master branch as my current default branch, because workflows can run automatically only on the default branch.
Last edit: Arki55 2023-08-09
Example of releases list in SourceForge
Created SF GitHub importer tickets:
- https://sourceforge.net/p/forge/feature-requests/867/
- https://sourceforge.net/p/forge/site-support/24888/
Working on alternative test build setup by using versioning info only.
But stumbled upon problems. For WIN build the EXE file must contain 4 numbers as part of version info. The last micro number can have only 5 digits. If MICRO has more, then EXE is generated with overflown version information and refuses to start.
Finally got it all changed and working. At least for the 2 deployment configurations - win32 UI + SDL
Changes:
feat: Nightly build workflow
More details:
- Before building, fuse_version constant will be replaced with a desired version in configure.ac.
- Before builds, master from configure parent repository will be merged into the current branch.
- The same happens also for Libspectrum, master from configured parent repo is merged before building.
- Failure to merge anything does not stop Libspectrum from building, but it stops Fuse. To save resources. When triggering the workflow manually, build can be enforced.
- Release tag changed to contain fuse version, branch name and date of last commit.
- Similarly like release tag, also individual zips containing builds will be named like fuse-<version>-<build key="">.zip.
- Two test build variants - STD as Standard (only version changes) or as TEST - displaying more info about the source of build in about dalog box.</build></version>
refactor: Replace text "the Free Unix Spectrum Emulator" with FUSE_LONG constant. Unify the sentence across usages.
refactor: Replace text "Fuse "+FUSE_VERSION with new constant FUSE_ABOUT_VERSION, replace dashes with spaces in it.
feat: Dynamic fuse version info + test version info in About box ( Widget UI )
- Version info will be read from constant FUSE_ABOUT_VERSION and split into lines, allowing splitting by words.
- In case of TEST BUILD, forwarded detailed version info lines will be printed as well
- Labels reordered so that the order is the same as in about box of WIN32 UI
- Code refactored to allow calculating of total lines needed for whole about dialog box
feat: Dynamic fuse version info + test version info in About box ( WIN32 UI )
- Version info will be read from constant FUSE_ABOUT_VERSION and split into lines by auto wrapping. Practically only 2 lines good.
- Size of dialog box enlarged in both dimensions to allow bigger version text line(s).
- In case of TEST BUILD, forwarded detailed version info lines will be printed as well. I had to create a separate .rc file for this thou.
Pull request in my GitHub clone:
https://github.com/arki55/fuse-fuse/pull/47/commits
Branch in SourceForge (arki55 clone)
https://sourceforge.net/u/arki55/fuse/ci/arki55/features/T13-github-distribution-workflow-final-3/~/tree/
Pull request for original Fuse SourceForge repo:
https://sourceforge.net/p/fuse-emulator/fuse/merge-requests/27/
Successful nightly build:
https://github.com/arki55/fuse-fuse/actions/runs/6804945044
Canceled nightly build (no new commits):
https://github.com/arki55/fuse-fuse/actions/runs/6806288527
Three days ago some fixes were merged into master, daily build detgected changes, pulled them, builds created, release files created and cloned into Sourceforge as well.
Hopefully fixed now the problem with daily builds not containing the last changes from the day before. As checkout by default takes only the revision hash provided by triggering event.
And as there is a merge done in the process, subsequent checkouts need to do full checkout and use the latest revision. Whih would not be visible otherwise.
For that the parameter fetch-depth:0 is used.