Trying to understand how this would work with CI/CD pipeline

[dalewking]

I started with reckon and it is working fine for the case of a repo that is just one project, but am looking to move to a repo housing multiple projects in one repo and that each can have their own versioning which is what your plugin is designed to do.

All your examples seem to be designed around the flow that a project is built and pushed from a developer machine and semver steps are manual invocations of gradle.

I am not sure how to make that fit into a CI/CD world where builds and publication are done in Jenkins based off a main branch and PRs. This works with reckon because i just set the stage to final or snapshot based on whether it is a PR build. When I need to bump up the major or minor version number I can simply do that by putting a prefix of major: or minor: in a commit message

I am trying to figure out what a similar workflow would be for this plugin. Lets say with the multiproject example and i am doing a PR that when merged needs to bump the major version number of project a, how might i accomplish that. In other words how can i automatically control the semver.scope of project a based only on what is in git?

It might be possible to devise something by scanning the commits and looking for something like a commit messsage that has a:major

[JavierSegoviaCordoba]

Hello!

If I have understood you correctly, you want to use snapshots by default in PRs, so you are covered with -P semver.stage=snapshot in your workflow. So, based on the last version, you would get:

• 1.0.0-alpha.1 -> 1.0.0-SNAPSHOT
• 1.0.0-rc.1 -> 1.0.0-SNAPSHOT
• 1.0.0 -> X.X.X-SNAPSHOT (this depends on which scope you indicate in the flow, if it is patch by default, then 1.0.1-SNAPSHOT.

When that PR is merged, you want to push a tag based on some part of the last commit message to decide what scope will be used for that tag. Currently, the plugin does not support anything related to this or conventional commits, but you should be able to do that in two consecutive steps. As I don't know how Jenkins works, I am going to write it in pseudocode:

- on push to the main branch

- jobs:
  - Push new version tag
    - Step 1: Extract the scope from the commit message and assign it to a variable
    - Step 2: Run Gradle with `./gradlew pushSemverTag -P semver.scope=$scope"

The complicated part is the Step 1

• Use git log -1 to get the last message and extract the scope by doing a substring before the first :, assign it to a variable, or as a step/job output. I don't have a lot of experience with bash but it should be doable, if not maybe you can use a Kotlin script.

For the Step 2, you can also use createSemverTag and do a "manual" push in CI (for example in a Step 3) if you want to do some checks before it is pushed.

Beside that, feel free to create a feature request for this, detailing how you would like to get this working. Without thinking a lot about this, probably -P scope.semver=git (or some better name) that would do the job for you.

My concern about that part is, you are indicating directly the scope in the commit message, and it could clash with a future implementation based on Conventional Commits, so we would need really good names for this and how if this would be designed to be only detected via Gradle Project properties (-P), or if git behavior would depend on an option added to the extension DSL:

enum class SemverMode {
    ConventionalCommits,
    LastCommitMessage,
    Default,
}

semver {
    mode = ConventionalCommits
}

[dalewking]

There is nothing complicated about Jenkins here it just runs the builds by invoking commands like you would it just always runs the same commands unless you put logic into it and this logic is more than should be in Jenkins. Right now the only logic I am using related to semver is to choose between stage final and snapshot based on whether the branch is main.

I do not want the developer pushing tags. Management of those tags should only be done in Jenkins.

The flow you indicated seems to indicate that you could never go from 1.0.0 to 1.1.0-SNAPSHOT. If a PR has a new feature in it then the snapshot version should also reflect that. But I do not want tags for snapshots

Conventional commits is exactly the thing I am looking for. The scope part is what should map to the various tag prefixes. So if I am on 1.0.0 and the commit contains a new feature for b then the commit should have feat(b): in the commit that says to bump to b1.1.0-SNAPSHOT for the PR build and b1.1.0 for the final build.

With conventional commits I would want a better mapping to scopes. Now it is kind of weird that you can sort of have 2 projects that can use the same tag prefix but have conflicting semver settings. Makes more sense to define all the semver stuff in one place, settings.gradle or the root project, and individual projects just say which scope to use.

You at least confirmed that I wasn't missing something and there isn't something out of the box.

[JavierSegoviaCordoba]

You can do a hackaround that can be publishing an alpha at the same time you publish the final one, for example, publishing 1.0.0 and in the same commit publishing a 1.1.0-alpha.1. Then you will get 1.1.0-SNAPSHOT