how do people handle versioning in gradle in CICD i saw some

Question

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 · Answer

Works just fine for me <https github com mpetuska kmdc blob master github workflows release yml|https github com mpetuska kmdc blob master github workflows release yml>

Big Chungus · Answer

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

sreich · Answer

hmmm

sreich · Answer

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

Big Chungus · Answer

Big Chungus · Answer

Nowhere it s fed in by creating github release

Big Chungus · Answer

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 · Answer

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

sreich · Answer

hmmm

sreich · Answer

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 · Answer

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 grinning

Big Chungus · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

that sounds lovely az pipelines here as well or at least that s my goal wink

Big Chungus · Answer

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 · Answer

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

Big Chungus · Answer

Not oss one I m affraid

Big Chungus · Answer

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

Javier · Answer

Javier · Answer

I created that one based on Reckon

wakingrufus · Answer

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 · Answer

awesome thanks guys