mirror of
https://github.com/garbagemule/MobArena.git
synced 2024-11-23 02:55:46 +01:00
798ae0f578
This commit makes the build workflow output the version string as found in the `version` property in `build.gradle.kts`. The version string will be necessary further down the pipeline when we need to extract release notes and create tags. There are many ways to extract the version string: - Use `grep` to grab it from `build.gradle.kts` directly. This is pretty brittle, since we don't really know for sure if the structure of the file will change in the future. - Create a Gradle task in `build.gradle.kts` that prints the version string. This is probably the most direct approach we could take, but such a hyper-specific task feels like a code smell. It also requires running Gradle again, which is a bit slow. - Use the built-in `properties` task in Gradle to print the `version` property and `grep` it. We avoid changing `build.gradle.kts`, which is a plus, but we still have to actually run Gradle. - Parse the filename of the resulting jar-file in `build/libs/`, since it now contains the version string. This is also brittle, because we don't know if we're gonna continue to append the version string to the jar-file, and depending so much on it being there is a little scary. - Extract `plugin.yml` from the resulting jar-file and `grep` it. This is perhaps a little crude, but it is much faster than running Gradle, and as a bonus, we get a bit closer to "what's inside the jar-file", which should give us a bit more confidence that any given release is actually the version it claims to be. It may seem like a small thing to invest so much text on, but from an automation standpoint, it is much easier to be confident in automations with predictable and robust mechanisms for deriving input variables. |
||
---|---|---|
.. | ||
ISSUE_TEMPLATE | ||
workflows | ||
CONTRIBUTING.md | ||
PULL_REQUEST_TEMPLATE.md |