how do people handle versioning in gradle in CICD?...

# gradle

[sreich]

how do people handle versioning in gradle in CICD? i saw somebody throwing around the idea of not having the version embedded in a file but rather a part of the CICD system, like as a variable that it pulls in. Which I don't think would even work? What are your thoughts, what are some standards?

[Big Chungus]

Works just fine for me. https://github.com/mpetuska/kmdc/blob/master/.github/workflows/release.yml

[Big Chungus]

Version is determined by gh release tag which then triggers release build pipeline

[sreich]

hmmm

[sreich]

where is your version being specified, like in the build.gradle though?

[Big Chungus]

https://github.com/mpetuska/template-kmp-library

[Big Chungus]

Nowhere, it's fed in by creating github release

[Big Chungus]

By default it's 0.0.0-SNAPSHOT specified in gradle.properties, but that's optional and only there for aesthetics when working locally

[Big Chungus]

Basically gh release name/tag becomes the version in the builds that are triggered by it

[sreich]

hmmm

[sreich]

that does make me a little uncomfortable that i wouldn't have it right with the code. but i can see the appeal of this

[Big Chungus]

Why would you need it hard coded? What are your use-cases for that? Are you sure it's not just "the way you got used to"? 😀

[Big Chungus]

Hard coded versions only make sense in git flow workflows (somewhat). In trunk you have tags to clearly mark up your git history in terms of versioning anyways and the rest of the trunk is always "live"

[sreich]

there is certainly some of that. That and uneasiness. I'm in an enterprise environment where we have a test environment that can only run 1 instance/version of the code. So currently we use maven and will create feature branches...say with 2 different devs working on an app. But that means there is only 1 -SNAPSHOT version that "wins"

[sreich]

but having to avoid all of the extra nonsense like addition CICD commits back to increment the version via SNAPSHOT after a release, and things like that woudl be awesome to finally be rid of

[Big Chungus]

I had my env builds use a list of tags in the dropdown as input (az pipelines) which made deploying test envs super clear and easy

[sreich]

that sounds lovely. az pipelines here as well. or at least, that's my goal 😉

[Big Chungus]

I always find that linking hard coded versions to pipeline contexts is usually a lor harder than it should be. Having version as a pipeline-only entity makes the orchestration a lot easier

[sreich]

okay, that sounds good to me. you don't happen to have a az pipeline example you can share do you?

[Big Chungus]

Not oss one I'm affraid

[Big Chungus]

But in short, i used az pipelines to produce tags and artefacts an then az releases to consume them and do deployments

[Javier]

https://github.com/JavierSegoviaCordoba/semver-gradle-plugin

[Javier]

I created that one based on Reckon

[wakingrufus]

i like triggering releases on git tags, then parsing the tag to pass in the gradle -Pversion property to the build. i have a github action that shows this: https://github.com/wakingrufus/JaMM/blob/main/.github/workflows/release.yml

[sreich]

awesome, thanks guys