[GITHUB] Add weekly pre-releases workflow for Generals and GeneralsMD #929

fbraz3 · 2025-05-24T19:09:41Z

What this PR does?

This PR complements #1171

Creates a github action to create a weekly release with the latest code changes. It will be scheduled to every moday.

https://github.com/fbraz3/GeneralsGameCode/actions/runs/15689781515

It also can be mannualy triggered, and it have parameters to bypass the code changes check to force a new build

The release notes also have a changelog with all commits since the last release - for the first release it will be limited to the last 10 commits

xezon · 2025-05-24T19:29:03Z

What does this change produce then?

roossienb · 2025-05-24T19:50:31Z

If these are our 'official' pre-releases then they need to be properly versions.

fbraz3 · 2025-05-24T20:05:13Z

If these are our 'official' pre-releases then they need to be properly versions.

I can adjust for a semVer schema if it looks better.

fbraz3 · 2025-05-24T20:07:12Z

What does this change produce then?

It will produce zip files weekly with the main executables for generals, worldbuilder and w3dview both for both games.

roossienb · 2025-05-25T12:37:42Z

If these are our 'official' pre-releases then they need to be properly versions.

I can adjust for a semVer schema if it looks better.

It's not about looking better, it's about having traceability when somebody reports an issue or bug.

fbraz3 · 2025-05-25T22:42:00Z

@xezon @roossienb I’ve just updated the pull request to use semantic versioning.

The version is now based on .github/workflows/base-version.txt and the patch level is incremented automatically at build time.

When the project is ready for a stable release, we just need to update the version file to 1.0.

I ran the workflow on my fork and everything went smoothly:
https://github.com/fbraz3/GeneralsGameCode/actions/runs/15241083502
https://github.com/fbraz3/GeneralsGameCode/releases

roossienb · 2025-06-02T19:42:44Z

In a discussion with @Mauller he told me that they did nightly builds in which they used the latest commit number as the build number in the application. This makes it easy to track back.

fbraz3 · 2025-06-04T03:52:53Z

In a discussion with @Mauller he told me that they did nightly builds in which they used the latest commit number as the build number in the application. This makes it easy to track back.

It’s fine to change the logic to whatever is needed. But just need to decide what will be the pattern.

All approaches have its own pros and cons. Using latest commit it’s a good approach but we can get more than one commit in a day, and this would be a problem to track anyway.

What about to mix the approaches like 0.9.{commit_id} or 0.9.{release_date} ?

roossienb · 2025-06-04T18:01:09Z

I think most important is that the version is also shown in-game (so when you open the options menu, in the bottom).

fbraz3 · 2025-06-04T19:46:58Z

I think most important is that the version is also shown in-game (so when you open the options menu, in the bottom).

I totally agree with you. But I don’t have enough knowledge in C language. Can you guys help me to do that?

OmniBlade · 2025-06-09T10:04:52Z

I don't think it should have a proper version number tag, only official releases should get a version tag and otherwise should show the commit and if the tree was dirty when it was built. Vanilla Conquer uses a GitWatcher cmake module to populate the variables used to configure this file which is then referred to when configuring the version.

fbraz3 · 2025-06-10T16:52:25Z

I don't think it should have a proper version number tag, only official releases should get a version tag and otherwise should show the commit and if the tree was dirty when it was built. Vanilla Conquer uses a GitWatcher cmake module to populate the variables used to configure this file which is then referred to when configuring the version.

I think I’m getting close to add the build version to game.

I believe in a few days I will be able to update this pr with the modifications.

fbraz3 · 2025-06-12T19:58:30Z

@xezon @roossienb @OmniBlade @tintinhamans

I've update the first comment of this PR with the latest changes.

OmniBlade

I think there needs to be some thought as to how these releases are differentiated from our "official" releases. As I've already commented, I think semver should be reserved for final release versions.

I also don't get what the vesion text files get us that can't be just stored in git itself as tags?

OmniBlade · 2025-06-24T09:36:31Z

.github/workflows/base-version.txt

@@ -0,0 +1 @@
+0.9.1


I think this versioning should be left out of the weekly builds completely personally.

I agree. We can make the versioning enterily independent of the CI.

OmniBlade · 2025-06-24T10:00:54Z

.github/workflows/weekly-release.yml

+            echo "changed=true" >> $GITHUB_OUTPUT
+          fi
+
+  calculate-version:


What benefit do we get creating these files to be moved around rather than just calculating the information and storing it in variables where the workflow requires it?

This is needed by build-toolchain and will be used in C++ counterpart here and here

xezon · 2025-06-24T11:53:11Z

I do think our previews and releases should only contain the vc6 + tools builds, no win32, no extras. Because the win32 is not meant to be used by players at this time.

fbraz3 · 2025-06-25T18:31:10Z

What about this approach?

Generate a file on the GitHub Actions side to populate the version.

This is already happening in the weekly build — we just need to add it to the CI process as well.
The C++ code will read this file and display its contents as-is.

This allows us to:

Generate weekly releases with custom names (e.g., pre-release, preview, etc.)
Add a CI build step to populate the version file with the current commit ID
Add a form field for manual releases to override the version string

xezon · 2025-06-25T21:04:03Z

If the CMake can generate the version, then is it fine to use that instead?

fbraz3 · 2025-06-25T21:56:43Z

If the CMake can generate the version, then is it fine to use that instead?

Although I don’t have experience in c/c++ coding, I can try to do it.

What will be the version pattern? Just the git version?

xezon · 2025-06-25T21:59:27Z

I can do that, because I already have all the code here to facilitate this.

fbraz3 · 2025-06-26T02:07:38Z

I can do that, because I already have all the code here to facilitate this.

Great!

Just to make sure we're on the same page, for this PR I need to:

Remove the version generation logic from weekly-release
Roll back the version logic in build-toolchain
Change the release title format to preview-YYYY-mm-dd
Remove the Win32 builds

Anything else?

xezon · 2025-07-06T13:38:38Z

Yes that would be good.

So for versioning I have prepared change #1219 that uses a CMake script to generate an additional git version file for C++ which looks like so:

GeneralsGameCode/resources/gitinfo/gitinfo.cpp.in

Lines 20 to 28 in 0f0352e

    
           const char GitSHA1[] = "@GIT_HEAD_SHA1@"; 
        
           const char GitShortSHA1[] = "@GIT_HEAD_SHORT_SHA1@"; 
        
           const char GitCommitDate[] = "@GIT_COMMIT_DATE_ISO8601@"; 
        
           const char GitCommitAuthorName[] = "@GIT_AUTHOR_NAME@"; 
        
           const char GitTag[] = "@GIT_TAG@"; 
        
           time_t GitCommitTimeStamp = @GIT_COMMIT_TSTAMP@; 
        
           bool GitUncommittedChanges = @GIT_IS_DIRTY@; 
        
           bool GitHaveInfo = @GIT_RETRIEVED_STATE@; 
        
           int GitRevision = @GIT_REV_LIST_COUNT@;

We can generate another version of this in CMake that the CI could read, in Json format or just Plain text: whatever works.

Additionally we write game version information in

GeneralsGameCode/GeneralsMD/Code/Main/CMakeLists.txt

Lines 30 to 47 in 477be26

    
           file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/GeneratedVersion.h 
        
           "#pragma once 
        
           #define VERSION_LOCALBUILDNUM 0 
        
           #define VERSION_BUILDUSER \"Someone\" 
        
           #define VERSION_BUILDLOC \"Someplace\" 
        
           " 
        
           ) 
        
           # Based on original binary values for these variables. 
        
           file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/BuildVersion.h 
        
           "#pragma once 
        
           #define VERSION_MAJOR 1 
        
           #define VERSION_MINOR 4 
        
           #define VERSION_BUILDNUM 601 
        
           " 
        
           )

For in game versioning, I currently settled on:

Version VERSION_MAJOR.VERSION_MINOR R @GIT_REV_LIST_COUNT@ By VERSION_BUILDUSER

Which in turn should look like so:

Version 1.04 R 550 By The Super Hackers

For VERSION_BUILDUSER we do not yet have logic in place to actually generated the string from CI. So that is something we would need to add (in this change).

I think CI needs to:

Tell CMake what the VERSION_BUILDUSER should be before generating CMake
Build the games with CMake
Read relevant files that CMake has generated to get game version information

Do you think you can work with this information? Do you need assistance? I can help with the CMake side of things.

I think we need to finalize #1219 first.

xezon · 2025-07-16T07:32:33Z

#1219 was merged and CMake now generates git version information. The git version information is generated in the resources target. And the game version information is generated in the z_generals, g_generals targets. There will be more changes necessary to get the CI involved.

I have another change #1291 lined up that makes some changes to the game version information.

After this we need to make another pass on git + game version how we combine them better.

I think game version also needs to be moved to resources target, so that it could also be reused in tools!

fbraz3 · 2025-07-16T20:34:12Z

Hey @xezon sorry for a long delay, i'm facing some personal issues and not had much time last weeks. I Intend to work on CI side this weekend. I keep in touch if i have some trouble in the C++ part. I'm also available to schedule some pair programming if needed.

fbraz3 · 2025-07-21T14:40:24Z

@xezon I have updated the code on GitHub to change the release logic and add VERSION_BUILDUSER to the build toolchain. I also added the option to manually include build notes and known issues (as optional fields) for manual releases.

fbraz3 · 2025-07-21T14:54:13Z

Just another question: I noticed in the project README that Linux compatibility is listed as 100%. Would it be possible to provide build instructions for Linux? If so, I could consider adding a Linux build to the CI process as well.

xezon

Do you have a sample for what this workflow currently generates? Is it complete or is it missing anything?

xezon · 2025-07-21T16:41:18Z

.github/workflows/build-toolchain.yml

@@ -112,6 +116,10 @@ jobs:
          "-DRTS_BUILD_ZEROHOUR=${{ inputs.game == 'GeneralsMD' && 'ON' || 'OFF' }}",
          "-DRTS_BUILD_GENERALS=${{ inputs.game == 'Generals' && 'ON' || 'OFF' }}"
          )
+
+          if ("${{ inputs.release }}") {
+              $buildFlags += "-DVERSION_BUILDUSER='${{ inputs.release }}'"


What does inputs.release evaluate to? The variable name is strange.

I made a mistake and thought that simply adding the VERSION_BUILDUSER parameter to CMake would be enough, but now, looking more closely, I realize there is some logic in the C++ part that I need to review as soon as possible.

I've just changed the input name to release-name and cmake flag to RELEASE_NAME and will work on C++ counterpart. I'm also open to suggestions for a better variable name.

OmniBlade · 2025-08-08T09:09:56Z

.github/workflows/weekly-release.yml

+      - name: Create GitHub Release
+        uses: softprops/action-gh-release@v2
+        with:
+          tag_name: preview-${{ needs.get-date.outputs.date }}


Looking at this the format for the release name/tag should be preview-$DATE, but the most recent runs on your repo don't reflect that despite it being 2 weeks since you last pushed the branch? I'm guessing you need to push it to main for that to happen or something? Just wanted to check the output before I gace it the okay.

Also, do we want to call it "preview" which implies its just an early release of what could be final when in practice that won't be the case? Maybe just prefix "weekly" instead? Thoughts?

"weekly" is also fine

Maybe "weekly-preview" :D

Hey Guys,

@OmniBlade my fork uses a different versioning schema (semVer) - in this schema 0.x versions implies that is a pre/beta release. For superhackers project we agreed to use a date-based versioning. Just need to decide if we want to user preview-$date or weekly-preview-$date and I will change in asap.
imho using weekly or nightly naming automatcaly implies in a non production-ready version so the preview tag could not necessary.

@xezon just send a change to override the version name using the RELEASE_NAME build flasg in toolchain. This cmake change is suggested by copilot, so i'm not sure if it will work properly if you can suggest something better i would appreciate.

I'm also available for a pair programming if you guys find useful, it will be a great opportunity for me to learning a bit of c++ from more skilled engineers =)

How does the version string now look in the game?

xezon · 2025-08-10T15:26:46Z

.github/workflows/weekly-release.yml

+      - name: Download GeneralsMD VC6 Artifacts
+        uses: actions/download-artifact@v4
+        with:
+          name: GeneralsMD-vc6+t+e


I suggest to simply use the entire GeneralsMD-vc6+t (not GeneralsMD-vc6+t+e). It has all useful tools and the game. No need to peek inside the archive and filter its contents again.

xezon · 2025-08-10T15:41:42Z

.github/workflows/weekly-release.yml

+      - name: Create GitHub Release
+        uses: softprops/action-gh-release@v2
+        with:
+          tag_name: preview-${{ needs.get-date.outputs.date }}


How does the version string now look in the game?

xezon · 2025-08-10T15:45:09Z

.github/workflows/weekly-release.yml

+        include:
+          - preset: "vc6"
+            tools: true
+            extras: true


The extras would not be necessary here. We do not need to release the extra tools.

xezon · 2025-08-10T15:59:38Z

.github/workflows/build-toolchain.yml

@@ -110,6 +114,10 @@ jobs:
          "-DRTS_BUILD_ZEROHOUR=${{ inputs.game == 'GeneralsMD' && 'ON' || 'OFF' }}",
          "-DRTS_BUILD_GENERALS=${{ inputs.game == 'Generals' && 'ON' || 'OFF' }}"
          )
+
+          if ("${{ inputs.release-name }}") {
+              $buildFlags += "-DRELEASE_NAME='${{ inputs.release-name }}'"


It would be good to set the following defines:

VERSION_BUILDUSER="The Super Hackers" VERSION_BUILDLOC="https://github.com/TheSuperHackers/GeneralsGameCode" VERSION_BUILDNUM=<The number of total builds>

For version number we currently use the Git Revision number which is ok.

The files that are generated for VERSION_BUILDUSER etc probably need updating to:

file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/GeneratedVersion.h "#pragma once #ifndef VERSION_BUILDNUM #define VERSION_BUILDNUM ${BuildNumber} #endif #ifndef VERSION_LOCALBUILDNUM #define VERSION_LOCALBUILDNUM 0 #endif #ifndef VERSION_BUILDUSER #define VERSION_BUILDUSER ${BuildUser} #endif #ifndef VERSION_BUILDLOC #define VERSION_BUILDLOC ${BuildLocation} #endif " )

or a variation thereof

fbraz3 · 2025-08-14T00:58:35Z

@xezon , I've made some major changes to the codebase here.

Summary of Changes

The primary modification is how the version string is displayed on the options screen.

For standard CI builds (from feature branches, etc.), the version string format remains unchanged:
Community Patch ~X by XXXX | exe:xxxxx ini:xxxx Version 1.04
For release or pre-release builds generated by the weekly build process (whether scheduled or manually triggered), the version string will now follow this pattern:
Community Patch by BUILD_USER release RELEASE_NAME - Version 1.04

How It Works

The weekly-release.yml workflow sends release-name, build_user, and build_loc to the build toolchain.
Standard CI processes do not send these parameters.
The build toolchain treats these values as optional, defaulting to empty strings if they aren't provided.
If the parameters are set, the toolchain passes them to CMake.
The C++ code then reads these build parameters. If they are not blank, it changes the output string on the options screen accordingly.

xezon requested a review from tintinhamans May 24, 2025 19:14

xezon added Major Severity: Minor < Major < Critical < Blocker Build Anything related to building, compiling labels May 24, 2025

fbraz3 force-pushed the weekly-release branch from 5deb762 to 8bf3e71 Compare May 24, 2025 19:36

fbraz3 force-pushed the weekly-release branch 4 times, most recently from d248576 to b668cf2 Compare May 25, 2025 18:35

fbraz3 force-pushed the weekly-release branch 5 times, most recently from 09d1dd0 to a801bfb Compare June 10, 2025 00:58

fbraz3 force-pushed the weekly-release branch from 034939d to 517791e Compare June 12, 2025 00:26

OmarAglan mentioned this pull request Jun 12, 2025

[GitHub] Uploads the Build Artifacts To Simple Website Using GitHub P… #910

Closed

fbraz3 force-pushed the weekly-release branch from 517791e to 029b6fb Compare June 12, 2025 14:09

fbraz3 force-pushed the weekly-release branch from 029b6fb to df20da3 Compare June 16, 2025 19:09

OmniBlade requested changes Jun 24, 2025

View reviewed changes

roossienb mentioned this pull request Jul 4, 2025

Create guide for getting the pre-built binaries TheSuperHackers/GeneralsWiki#46

Open

prettyblueberry mentioned this pull request Jul 20, 2025

Play a mod using GenLauncher #1317

Open

fbraz3 force-pushed the weekly-release branch 2 times, most recently from 154a6aa to 23fb099 Compare July 21, 2025 14:35

xezon reviewed Jul 21, 2025

View reviewed changes

xezon requested a review from OmniBlade July 21, 2025 16:44

fbraz3 force-pushed the weekly-release branch 2 times, most recently from 1e3014b to 02f4b33 Compare July 25, 2025 20:49

OmniBlade reviewed Aug 8, 2025

View reviewed changes

fbraz3 force-pushed the weekly-release branch 2 times, most recently from 8fa4434 to 9d81587 Compare August 10, 2025 01:59

xezon reviewed Aug 10, 2025

View reviewed changes

fbraz3 force-pushed the weekly-release branch 3 times, most recently from d04501c to 9746f58 Compare August 11, 2025 18:45

[GITHUB] Add weekly pre-releases workflow for Generals and GeneralsMD

ad803af

fbraz3 force-pushed the weekly-release branch from 9746f58 to ad803af Compare August 14, 2025 00:43

		@@ -0,0 +1 @@
		0.9.1

[GITHUB] Add weekly pre-releases workflow for Generals and GeneralsMD #929

Are you sure you want to change the base?

[GITHUB] Add weekly pre-releases workflow for Generals and GeneralsMD #929

Uh oh!

Conversation

fbraz3 commented May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xezon commented May 24, 2025

Uh oh!

roossienb commented May 24, 2025

Uh oh!

fbraz3 commented May 24, 2025

Uh oh!

fbraz3 commented May 24, 2025

Uh oh!

roossienb commented May 25, 2025

Uh oh!

fbraz3 commented May 25, 2025

Uh oh!

roossienb commented Jun 2, 2025

Uh oh!

fbraz3 commented Jun 4, 2025

Uh oh!

roossienb commented Jun 4, 2025

Uh oh!

fbraz3 commented Jun 4, 2025

Uh oh!

OmniBlade commented Jun 9, 2025

Uh oh!

fbraz3 commented Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fbraz3 commented Jun 12, 2025

Uh oh!

OmniBlade left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xezon commented Jun 24, 2025

Uh oh!

fbraz3 commented Jun 25, 2025

Uh oh!

xezon commented Jun 25, 2025

Uh oh!

fbraz3 commented Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xezon commented Jun 25, 2025

Uh oh!

fbraz3 commented Jun 26, 2025

Uh oh!

xezon commented Jul 6, 2025

Uh oh!

xezon commented Jul 16, 2025

Uh oh!

fbraz3 commented Jul 16, 2025

Uh oh!

fbraz3 commented Jul 21, 2025

Uh oh!

fbraz3 commented Jul 21, 2025

Uh oh!

xezon left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fbraz3 commented May 24, 2025 •

edited

Loading

fbraz3 commented Jun 10, 2025 •

edited

Loading

fbraz3 commented Jun 25, 2025 •

edited

Loading

fbraz3 Aug 10, 2025 •

edited

Loading