Improve in-game display of module versions - release/snapshot, git hash #3888
Labels
Category: Build/CI
Requests, Issues and Changes targeting gradle, groovy, Jenkins, etc.
Topic: Architecture
Requests, Issues and Changes related to software architecture, programming patterns, etc.
Summary
The game reads module version info out of
module.txt
to display on the Advanced Game Setup screen listings likeCore:3.0.1
orCities-1.0.0-SNAPSHOT
We don't bump module versions often enough to have a high degree of confidence that what the game is showing actually matches a specific version of module code.
Gradle uses metadata the game could perhaps also utilize, in two primary ways
-SNAPSHOT
to indicate dev buildsDetailed background
After #3871 Gradle now is better at deducing versioning for a module based on the environment.
module.txt
can just contain"version" : "3.0.1"
and Gradle finds out if it is a snapshot or a release - details in that PR.This helps Jenkins determine whether it should publish a release, a snapshot, or nothing at all.
The game zip still just gets whatever we stick into the built module jar file, which includes an unmodified
module.txt
and remains blissfully unaware of what Gradle thinks.Doing this avoids having to toggle on and off the
-SNAPSHOT
in code, and is one step closer to not necessarily managing version in code at all (Git tags etc). But there are two drawbacks:We need to make the game smarter: Either we update the
module.txt
on the fly during jar builds (which still doesn't help when running from source) or we deduce extended version info based on the environment.Scenarios
Built jar from Jenkins
In this case we could simply update Gradle to modify the
module.txt
being copied into the jar. We have access to the Git hash of the branch being built.Core:3.0.1
-SNAPSHOT
soCore:3.0.1+abc123
("build metadata" as per the SemVer specification follows a+
)Running from source
In this case I'm not sure. We can't rely on automatic modifications to
module.txt
(probably?) so we should probably load context from the environment. Maybe modules present in source are automatically marked with their Git hash, while jars load frommodule.txt
like from JenkinsGame reading new metadata
While updating `module.txt is easy enough reading it might be trickier, if gestalt-module expects a given format. Both for display and module resolution. Especially if we need to make it context sensitive somehow. More a word of caution for possible research.
The text was updated successfully, but these errors were encountered: