-
Notifications
You must be signed in to change notification settings - Fork 77
[GITHUB] Add weekly pre-releases workflow for Generals and GeneralsMD #929
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
What does this change produce then? |
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 will produce zip files weekly with the main executables for generals, worldbuilder and w3dview both for both games. |
It's not about looking better, it's about having traceability when somebody reports an issue or bug. |
d248576
to
b668cf2
Compare
@xezon @roossienb I’ve just updated the pull request to use semantic versioning. The version is now based on When the project is ready for a stable release, we just need to update the version file to I ran the workflow on my fork and everything went smoothly: ![]() ![]() |
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 |
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? |
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. |
09d1dd0
to
a801bfb
Compare
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. |
@xezon @roossienb @OmniBlade @tintinhamans I've update the first comment of this PR with the latest changes. |
GadgetStaticTextSetText( labelVersion, versionString ); | ||
UnicodeString fullVersion; | ||
fullVersion.format(L"%s - TheSuperHackers %s", versionString.str(), SUPERHACKERS_VERSION_WIDE); | ||
GadgetStaticTextSetText(labelVersion, fullVersion); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you make the indentation of all 3 lines match the removed line? Same for the Zero Hour file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I use spaces instead of tabs for indentation in IntelliJ, so it looks aligned to me. I’ve just updated it to replace the spaces with tabs again.
fc02c01
to
813798a
Compare
Please move the version change to a new Pull Request because it is not related to pre-releases workflow. This relates to task #1010 |
I don't think we have anyone active right now who can review this CI stuff. |
I work as a devops for many years, maybe I can help the project on CI reviews. I'm also have a few ideas for a more standard gitflow and release process |
Will work on that this weekend. |
@xezon @roossienb @OmniBlade @tintinhamans @Mauller moved the game logic changes to a new PR as requested: #1171 |
Do we need the text file? Can't it calculate based on the last tag in git for the change log and then just set the release tag to something like "weekly-dd:mm:yy"? That will nicely separate it from full release versions that can use semver when we ge to that point? |
How can I play the pr-release build with GenLauncher to play a mod? |
use my fork for now. |
I tried already pre-release build of your fork. I replaced generals.exe and modded.exe in working genlauncher directory, but the genlauncher didn't run a mod correctly. |
My build uses the exact same code from SuperHacker's repository. Please open an issue for further analysis. |
@OmniBlade can you review this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the images. The resulting Release overview looks pretty good. Perhaps we can name this "Preview Version" instead of "Pre-Release"? Basically we want to communicate that auto published versions are not hand picked final releases and can contain side effects.
@@ -0,0 +1 @@ | |||
0.9.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this version value chosen?
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
