Yea automatic versioning. Which channel is better?

# android-architecture

[ursus]

Yea automatic versioning. Which channel is better?

[satyan]

None I guess since it's a kotlin slack

[ursus]

how is android-architecture kotlin?

[satyan]

Architecture for Android IN KOTLIN

[ursus]

automatic versioning for CI building an ANDROID app IN KOTLIN

[Ianmedeiros]

I suggest the building-system of the Android-United

[satyan]

You would have had the same question if you were using Java or anything else for your project. 🤣

[ursus]

same as for architecture questions, as they are per definition, language agnostic

[ursus]

tldr; dont enforce an imaginary rule and enjoy the sharing of knowledge

[satyan]

It's not imaginary. It's just this Slack etiquette.

Every channel is related to Kotlin.

Architecture might be language agnostic on surface but you still need an implementation of this architecture leveraging concepts and features from the languages you use.

Automatic versioning of your App using a CI server might be interesting but it's not Kotlin related. You could ask this on CircleCi forum or Android-United as suggested.

I don't think it's a bad rule to allow only Kotlin related questions. There are about 20k people here 🤷

[ursus]

its either both are unrelated, or both are related, howgh

[tschuchort]

I have wasted countless hours on this in the past few weeks. What I ended up doing is this:

• push triggers Gitlab CI pipeline
• the current version is defined as a variable in a separate SBT file (This was a Scala project)
• CI runs SBT release, which increments the version number in the version file, commits this file, publishes the Maven release, increments version file again to snapshot version, commits file again
• Because the CI runner commits stuff, it can no longer checkout the git repo in headless mode. This will lead to race conditions when a new commit is pushed while the CI pipeline is still running (particularly if it is in the middle of publishing the release)
• Because Gitlab CI runner does not have push access (and is impossible to give access), you have to hack around that. There is Gitlab documentation that suggests a workaround... it won't work. What you have to do is manually override all the remote URLs to use SSH instead of HTTPS and embed a personal access token in that URL.
• The publish/release step of the CI pipeline is only run on commits that don't match the commit message of the "increase version number" commits (or else it would lead to an endless loop). Gitlab CI YAML has the only and except attributes to filter based on commit message... For some reason I don't remember this doesn't work (does anything ever work on Gitlab?). So I have to parse the git commit message manually in the CI script and abort early.

[tschuchort]

Another thing you could do is to simply append the pipeline ID to your version number. It is always unique but you won't have semantic versioning anymore. Or perhaps it is better to keep the version numbering out of source code entirely and rely on git tags instead. Though tagging still requires push access which would probably lead to the same headless problems I mentioned above.
The whole thing is a mess really.

[tschuchort]

I have also explored the possibility to use an SBT (or Gradle in your case) plugin to read the latest available artifact version from the nexus repository. There is usually a maven-metadata.xml in the repository that contains all the available versions... Naturally our company's private nexus repo was misconfigured and didn't have it.

[ursus]

yea Im working on it rn, and am probably going to use CI_JOB_ID simply as a version code and thats it, semantic version will be bumped manually, its hard for a script to say whats a major minor anyways

[ursus]

although im still unsure about parallel jobs and gitlab ci, 2 jobs in a given stage can run parallel and therefore see common file system?

[ursus]

btw Ive seen a project where dude writes a file to parent file system and docker container can access it, and swears its docker running it but idk, for be it cannot see the path

[tschuchort]

In headless mode it checks out the particular commit/ref that the pipeline was started for. But that makes it impossible to commit because the ref may be anywhere within the tree. Instead you have to checkout the branch of the pipeline. But if the ref of the pipeline is unequal to the head of the branch then the pipeline will use the wrong commit.

[ursus]

yea.. is it a good idea that it a ci creates a commit?

[tschuchort]

No but what alternatives are there? You can tag the commit (but the pipeline may be triggered on a ref that is not a commit) or you can keep state outside the repo across pipeline runs which is just asking for trouble

[tschuchort]

My intuition is that tagging is the best approach

[ursus]

Well, you can exclude tags as a trigger, no?

[tschuchort]

How would that help?

[ursus]

you said tags trigger pipeline again

[tschuchort]

That too, but you can ignore tags in the publish step.