CI: upgrading checkout to version 4
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.
Merge remote-tracking branch 'repo/master' into arki55/master
Merge remote-tracking branch 'repo/master' into arki55/master
CI: Automated build and prerelease of branch arki55/testing
Revert "fix: Committer identity was missing. Added 2 new variables."
Merge remote-tracking branch 'repo/master' into arki55/master
Merge remote-tracking branch 'repo/master' into arki55/master
Merge remote-tracking branch 'repo/master' into arki55/master
Merge remote-tracking branch 'repo/master' into arki55/master
Merge remote-tracking branch 'repo/master' into arki55/master
fix: Committer identity was missing. Added 2 new variables.
CI: When building fuse, always use the latest revision.
CI: When fetching last commit from log, do not use merges.
ci: Fix date of last commit when packing release
fix: More precise ISO date detection
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.
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.
Merge remote-tracking branch 'origin/master' into arki55/features/T7-gray-out-peripherals-b
Merge remote-tracking branch 'origin/master' into arki55/features/T7-gray-out-peripherals-b
I've updated the source branch with latest master, fixed conflicts. But the merge commit is not visible neither in the branch nor in this pull request. Weird. I definitely pushed it. https://sourceforge.net/u/arki55/fuse/ci/0828519d7cc1bdcc5989588d1576ba38f1d89f73/log/?path=
It work again. Try committing something into master. It should trigger creation of new daily build the day after.
Yes, exactly. There were multiple varations, depending on the available port variant with 8255A chip (3x 8 bit ports in outgoing mode). Some had only 8 bits, some 4 bits switch as well. That's why I implemented 2 modes in options. Such as .. https://cygnus.speccy.cz/popis_da_pro_ase.php I tried to seach for the scheme I once used.. but failed.
Merge remote-tracking branch 'origin/master' into arki55/features/T2-DAC-interface-app
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}...
Yes, it is still a problem. Still the same error. https://github.com/arki55/fuse-fuse/actions/runs/6898788538/job/18800611623 error: RPC failed; curl 52 Empty reply from server fatal: the remote end hung up unexpectedly Error: Process completed with exit code 128.
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/
Unable to fetch repo from GitHub action servers
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.
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...
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...
feat: Nightly build workflow
feat: Dynamic fuse version info + test version info in About box ( WIN32 UI )
feat: Dynamic fuse version info + test version info in About box ( Widget UI )
refactor: Replace text "Fuse "+FUSE_VERSION with new constant FUSE_ABOUT_VERSION, replace dashes with spaces in it.
refactor: Replace text "the Free Unix Spectrum Emulator" with FUSE_LONG constant. Unify the sentence across usages.
feat: Nightly build workflow
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.
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.
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 ?
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. Is it maybe a bug in Cygwin ?
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,...
GitHub workflow for generating daily (master) builds
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.
Any possibility of merging this ?
Is there any general problem with this pull request? Or is this HW emulation just uninterested ? (and therefore should stay as my personal mod only)
HI, Build only if something got merged - OK, can be done. Also will help cut down on needed manual deletions in Source Forge. One drawback only. If something changes in Libspectrum, Fuse will have to be pinged manually. Version identification - if you're fine with setting official (sort of) version to such nightly build, then this does not need TEST build process. Only set "build" portion of version information before building. Would also remove the startup message. As you're right, these builds...
Daily master test build you have.. https://sourceforge.net/projects/arki55-fuse-mod/files/ It's merging master from origin project into arki55/master and builds it at 1 UTC. Can be later just master, if all workflow updates get there. Auto deletion works in GitHub, but not in SourceForge. Hopefully they fix that in the future.
Created SF GitHub importer tickets: - https://sourceforge.net/p/forge/feature-requests/867/ - https://sourceforge.net/p/forge/site-support/24888/
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/
GitHub test and nightly (master) build workflows + patches
Example of releases list in SourceForge
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...
GitHub workflow for generating test distributions (zips)
GitHub integration: Folder like structure of releases
GitHub integration: Sync deletion of older release(s)
Example of this bug from me https://sourceforge.net/projects/arki55-fuse-mod/files/test_arki55_features_T13-github-distribution-workflow-2/ Rcently I've been playing with automation workflow in Github around releases. There are some issues around README.md file. When source of release body is RELEASE.md file, the body gets synced to SourceForge, but the file itself not. Neither Zip files with source code get synced.. I had to add 2 release update actions, once updating files, then again updating...
Example of this bug from me https://sourceforge.net/projects/arki55-fuse-mod/files/test_arki55_features_T13-github-distribution-workflow-2/ Rcently I've been playing with automation workflow in Github around releases. There are some issues around README.md file. When source of release body is RELEASE.md file, the body gets synced to SourceForge, but the file itself not. Neither Zip files with source code get synced.. I had to add 2 release update actions, once updating files, then again updating...
Maybe I have formulated it wrongly.. now that I look at my message again. It does not force 48K mode, it switches ROM to 48K rom page, keeping 128K ram memory available. Would make sense if somebody made some SW for combination of that HW and 128K Spectrum. If there’s nothing like that, then indeed this is not needed at all.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:11.0pt; font-family:"Calibri",sans-serif;} MsoChpDefault {mso-style-type:export-only;} @page WordSection1...
Under windows, in SDL mode, it is not possible to increase or decrease the window size with the mouse (not full screen). Is that on purpose or a missing feature ?
ci: Remove unused workflow file
Hi I made a patch settings checkbox for combination D40 and Spectrum 128K. It limits IO address decoder by additional bit and forces 48k mode. Maybe it could be generalized for more use cases. Or add 48k mode of any Spectrum 128k as a separate settings checkbox. Arki55 Dňa st 26. 7. 2023, 7:56 "Sergio Baldoví" sbaldovi@users.sourceforge.net napísal(a): Works Currah uSpeech on a Spectrum 128K? I cant only work if I do a NMI and reboot into 48K mode. There is a positive post on WOS: https://worldofspectrum.org/forums/discussion/comment/149871/#Comment_149871...
Implemented second workflow: Nightly build Triggered automatically each night at 1 AM (CET) or manually. This workflow makes use of the TEST-BUILD workflow by providing specific arguments to it. Description will be: Nightly mater 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...
Implemented second workflow: Nightly build Triggered automatically each night at 1 AM (CET) or manually. This workflow makes use of the TEST-BUILD workflow by providing specific arguments to it. Description will be: Nightly mater 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...
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
GitHub workflow for generating test distributions (zips)
For those that want to test without building. Here's automated build/release for this branch. I myself don't have the needed roms, but the device is listed under sound HW. Only win32 + win SDL so far. Also, I'm interested in hearing what you think about these kind of builds. https://github.com/arki55/fuse-fuse/releases/tag/test_patches-142-currah-uspeech-deploy https://sourceforge.net/projects/arki55-fuse-mod/files/test_patches-142-currah-uspeech-deploy/ More about this feature here: https://sou...
Test-Build release in GitHub: https://github.com/arki55/fuse-fuse/releases/tag/test_arki55_features_T3-D40-plus-128K-final-deploy The same in SourceForge: https://sourceforge.net/projects/arki55-fuse-mod/files/test_arki55_features_T3-D40-plus-128K-final-deploy/
Test-Build release in GitHub: https://github.com/arki55/fuse-fuse/releases/tag/test_arki55_features_T2-DAC-interface-app-deploy The same in SourceForge: https://sourceforge.net/projects/arki55-fuse-mod/files/test_arki55_features_T2-DAC-interface-app-deploy/
ci: Test-Build deployment github workflow
ci: Trigger builds only on pull_request event.
feat: --with-test-build configure parameter.
GitHub workflow for generating test distributions (zips)
Implementation finished. First demo test build release published and synced into SourceForge (arki55) Windows win32 and windows SDL UI zipped builds available for download.
Implementation finished. First demo test build release published and synced into SourceForge (arki55) Windows win32 and windows SDL UI zipped builds available for download.
Implementation finished. First demo test build release published and synced into SourceForge (arki55) Windows win32 and windows SDL UI zipped builds available for download.
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 Pull request into master (the same repo) https://github.com/arki55/fuse-fuse/pull/33
GitHub workflow for generating test distributions (zips)
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
feat: Split widget messages on new line character.
chore: troubleshooting. moved test build warning message to UI independent source file.
chore: troubleshoo
chore: troubleshoot build
ci: Troubleshoot
ci: It should be enough if all build workflows execute on pull_request
fix: Tweaked step creating release. Tag name without slashes.
cd: Troubleshooting
cd: Troubleshooting, zip file was not included
cd: More params to create release command
cd: Replaced FTP with action that creates GH releases
cd: Bump up version of used FTP action
ci: troubleshoting uploading to ftp
chre: Troubleshooting
refactor: Reorganized deployent workflow files
fix: Troubleshooting uploading
chore: tweaking workflow displayed names
fix: Build dir path ends with -{UI}
dddd
fix: Passing on required secrets