Fuse - the Free Unix Spectrum Emulator / Patches / #439 GitHub workflow for generating daily (master) builds

Arki55 - 2023-10-12

A short update.

I've fixed merge from master that broke during August.

Tried to implement alternative mode of test build for nightly builds where the version information would be done only by using MICRO portion of version information in configure.ac. 6 digits as the date of the buid would suffice.

TO mu surprise this did not work correctly, as the generated EXE files were broken, did not want to start up. The reason being overflow version info of EXE file. Apparently that can contain only 5 digits, but YYMMDD is 6. By decreasing their cound to 5, binary was working again.

So the question is.. How to represent version in the win version info (see details of any EXE file) ? A counter would work, right, but not sure how to maintain it ? Even f I implement this as additional constant in configure.ac, file and package version still has to be filled out.

Any ideas?

fuse_p439_img1.png

fuse_p439_img2.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Arki55 - 2023-10-12

According to this page
https://learn.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource

Both FileVersion and ProductVersion should be identical data types = 4 x 16bit numbers.
Max. 16 bit = 65535. 5 digits. So how come that Micro in ProductVersion was able to display 6 digits?

Is it maybe a bug in Cygwin ?

Maybe I will just ditch MICRO, keep it as it is and introduce new constant for the about box only.

Last edit: Arki55 2023-10-12

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2023-10-14
  
  Is it maybe a bug in Cygwin ?
  
  Technically you are using mingw32 to compile C files and windres to compile the resource files. Windows is showing 6 digits, so the bug could be on Windows side, most likely an undefined behaviour when treating big version numbers.
  
  http://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/windint.h;h=73faabf85aa75728e9e7bd7a7e67bb7b48cd670a;hb=HEAD#l905
  
  http://sourceware.org/git?p=binutils-gdb.git;a=blob;f=binutils/resrc.c;h=468e2fd8fe1d82b072d92766f063a9b2fedccc79;hb=HEAD#l3273
  
  http://sourceware.org/git?p=binutils-gdb.git;a=blob;f=binutils/rcparse.y;h=0a5b9e0315a3aee4c02bd3667f49be8b981f7cc2;hb=HEAD#l1433
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Arki55 - 2023-10-13

So I figured the simplest way, bumping up nano + commit it
https://github.com/arki55/fuse-fuse/commit/b1e9ec4e3810a625935ad637a97a048c01399343

Also, I've noticed that the zin EXE file version info is from fuse_rc_version constant. Good, that means I can manipulate with the other one and extend it with "-20231013-master" or similar.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2023-10-14
  
  So I figured the simplest way, bumping up nano + commit it
  
  It would be better if you don't manipulate micro and nano version numbers as could by defined by an official release, e.g, version 0.10.0.2 or 1.0.0.1.
  
  Also, I've noticed that the zin EXE file version info is from fuse_rc_version constant. Good, that means I can manipulate with the other one and extend it with "-20231013-master" or similar.
  
  The fuse_rc_version constant needs exactly 4 tokens and can't be extended for EXE properties.
  
  I suggest extending the fuse_version for special builds (nightly build, release candidates, etc). This constant will be propagated to package name and about dialog:
  
  m4_define([fuse_version], [1.6.0-20231014])
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Arki55 - 2023-11-09

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

nightly_build_img1.png

nightly_build_img2.png

nightly_build_img3.png

nightly_build_img4.png

nightly_build_img5.png

nightly_build_img6.png

nightly_build_img7.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Arki55 - 2023-11-14

My happyness was premature. After few days it stopped working. Somehow SourceForge refuses to fetch changes from GitHub servers:

git fetch --prune
git remote add repo https://git.code.sf.net/p/fuse-emulator/fuse
git fetch repo

error: RPC failed; curl 52 Empty reply from server
fatal: the remote end hung up unexpectedly
Error: Process completed with exit code 128.

https://sourceforge.net/p/forge/site-support/25199/

Last edit: Arki55 2023-11-14

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Arki55 - 2023-11-23

It work again. Try committing something into master. It should trigger creation of new daily build the day after.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Arki55 - 2024-01-26

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.

2024_01_26_21_03_29_Workflow_runs_arki55_fuse_fuse_GitHub.png

2024_01_26_21_07_29_Automated_nightly_build_and_pre_release_arki55_fuse_fuse_b263d3d_GitHub.png

2024_01_26_21_07_52_ArkiFuse_Arki_s_mod_of_FUSE_emulator_Manage_Files_at_SourceForge.net.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

GitHub workflow for generating daily (master) builds

Group

Searches

Help

#439 GitHub workflow for generating daily (master) builds

Discussion