ci(release): Add weekly pre-releases workflow for Generals and GeneralsMD

[fbraz3]

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]

What does this change produce then?

[Skyaero42]

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

[fbraz3]

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]

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.

[Skyaero42]

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]

@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

[Skyaero42]

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]

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} ?

[Skyaero42]

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

[fbraz3]

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]

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]

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]

@xezon @roossienb @OmniBlade @tintinhamans

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

[xezon]

How does the version string now look in the game?

[xezon]

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]

done

[fbraz3]

@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.

1. 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

2. 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]

This needs another pass, reverting the string mutations and string presentations in the game. Please try to fit CI strings into the established formats.

Feed the Product Title, Product Version and Product Author from CI.

[xezon]

This is not ideal. Git Info should be taken as is and not be mutated for other purposes. If new information is added, then it should be explicit with new names and fields.

[xezon]

This was previously localized.

[xezon]

I think exe and ini must not be omitted here. Both EXE and INI hashes are critical information for Game Client compatibility.

[xezon]

Why was this removed? The purpose of configurable Product information is to allow Mods to override this Product information from Data.

If you want to set a new production version put that into the function:

UnicodeString Version::getUnicodeProductVersion() const
{
	UnicodeString version = getBuildVersion();
	if (version.empty())
		version = getUnicodeGitVersion();
	return version;
}

[xezon]

Why is this building an entirely new string variant for the CI Build? Instead I think we should feed the existing ProductName, ProductVersion and ProductAuthor from CI. That is what it was made for.

I suggest use the existing framework and fit the CI data in there, with priority over the git/other values. And do not override the git information. Just add new raw information as new fields.

[xezon]

Is it possible to get a CI build count number here instead of git commit count?

[xezon]

I think this should always be generated as is. No custom mutation of Git data.

[OmniBlade]

Maybe we drop the embedding of information from the CI for now as it is proving controvertial for exactly the best method to do so and just focus on producing weeklies as is from the CI? Embedding alternative build info from the CI can be a separate PR.

[fbraz3]

Maybe we drop the embedding of information from the CI for now as it is proving controvertial for exactly the best method to do so and just focus on producing weeklies as is from the CI? Embedding alternative build info from the CI can be a separate PR.

No problem to change the pr to only build in this first moment. will change the code and request a new review.

[fbraz3]

@xezon @OmniBlade Just to start a parallel discussion about the versioning system itself:

In my opinion, the CI pipeline should be the single source of truth for versioning. This aligns with what’s considered best practice in the literature (Continuous Delivery – Humble & Farley, Build Automation – Fowler, and SemVer.org). Version numbers should reflect intentional release decisions, while commit hashes and build metadata are generated automatically. CI is the natural place to bring those together in a consistent way.

If we allow local builds to stamp arbitrary versions (date, hash, etc.), we risk drift: the same code might exist under multiple “versions” depending on who built it. By centralizing version stamping in CI, every official artifact can always be traced back to its exact commit and release tag, without mutating Git metadata. Local builds can still include fallback info (like “dev” or build time) for debugging, but those shouldn’t override what CI assigns.

This approach also gives us governance: only CI-published builds carry an official version identifier. That makes it clear which artifacts are “real releases” versus developer builds, and keeps the history consistent and auditable.

[xezon]

This is an open source project, so anyone will be able to generate any version information in the game client as he likes. So even if we generate a version in CI, someone can replicate it locally.

We currently build version information locally with a mix of Product Name, Git Author and Commit count. From CI you can set a Product Name, Product Version and Product Author, which is different from what is auto generated.

Example:

Locally Generated: "Community Patch 752 By Mauller"
CI Generated: "Community Patch 0.1.752 By The Super Hackers"

0.1.752 meaning
Major Product Version = 0
Minor Product Version = 1
Commit Count = 752

[fbraz3]

That’s true for any open source project — anyone can fork the repo and stamp whatever version string they want into their local builds. But that doesn’t reduce the value of CI-generated versioning. The real distinction is not whether the string can be replicated, but whether it represents an official artifact or just a local build.

The real value of CI versioning is giving us a single, consistent scheme for official artifacts. Local builds can still show commit/author info for debugging, but CI builds are what the community can trust as authoritative releases. That separation keeps things clear for both contributors and players.

[xezon]

Is it possible to see a current example Release based on this workflow?

[fbraz3]

Is it possible to see a current example Release based on this workflow?

[fbraz3]

@xezon @OmniBlade what is still needed to merge this pr?

[OmniBlade]

This looks okay to me now, lets get it merged and if it needs further tweaking so be it.