This message was deleted.
# community-support
s
This message was deleted.
g
There are several of them depending on your workflow. I currently use
nebula.release
(calculates version base on git tags, create new tags etc) with publishing triggered by tag pushed to remote repo. What I certainly like with this one is versions like `1.2.0-dev.7.uncommitted+quarkus.migration.deadbee`: previous tag was 1.1.x, so incremented minor version by default +
-dev
suffix,
7
is number of commits since that tag,
uncommitted
for dirty repo state (some uncommitted changes present in worktree),
quarkus.migration
produced from feature branch name
quarkus-migration
and last token
deadbee
is last git commit id.
v
I use the
net.researchgate.release
plugin. I is much like the Maven release process, and afair also was designed to be similar. It cannot calculate the version from Git history, but it will un-snapshot on release, increase afterwards, commit, tag, push, ... But I actually greatly dislike calculating version from Git history, at least if it is the sole source of version, because that always requires the Git repository to do a simple build. You cannot for example build from a source ZIP.
1
g
I used it before (alongside maven release plugin for other projects). My case is for internal projects with git-first approach so it works for me since I don't need to publish separate source tgz/zip. I also dislike classic snapshot versions without commit info or similar meta to trace where deployed artifact came from. So it's matter of preference, I guess.
v
I ususally generate the commit info and dirty state into a properties file if Git is available, so the info is there, just not in the version number 🙂
r
Thank you Grossws and Vampire for your help, i will try both and let you know.
g
iirc there were some other plugins for using both approaches
r
@grossws I tried nebula release struck with this error: * What went wrong: Execution failed for task ':releaseCheck'.
Branch OPS-14338 does not match one of the included patterns: [master, HEAD, main, (release(-|/))?\d+(\.\d+)?\.x, v?\d+\.\d+\.\d+]
I tried with this configuration
Copy code
nebulaRelease {
    Set<String> releaseBranchPatterns = [/master/, /HEAD/, /OPS-14338/, /main/, /(release(-|\/))?\d+(\.\d+)?\.x/, /v?\d+\.\d+\.\d+/] as Set
  //  addReleaseBranchPattern(releaseBranchPatterns)
}
It didn't work.
g
I'm not sure why you want to create tag from issue based branch like that. What release management approach and branching model in git do you use?
v
Independent of that, you are creating and setting a local variable. How should that change anything in the plugins configuration?
The readme of that plugin is just very user-unfriendly and misleading
r
We are using GIT, for versioning, we are using major.minor.patch version model. As of now we have following command in jenkins pipeline for release branches:
Copy code
mvn build-helper:parse-version versions:set -DnewVersion=\\${parsedVersion.majorVersion}.\\${parsedVersion.minorVersion}.\\${parsedVersion.nextIncrementalVersion} versions:commit
This will basically bump of version. I am looking something similar, please let me know if you need any details. I declared version in gradle.properties, earlier it was in pom.xml
v
That is exactly what the researchgate plugin does during the release process, but it can of course also be triggered manually.
r
okay then i will try that
g
Ahh, I missed that
addReleaseBranchPattern
is commented. @Ramesh Vangala, try plugin that @Vampire suggested. It'll likely fit your current model much better.
r
yes, trying. I commented as it was not working.
v
It probably was not commented and then complained that the signature is not found when executing the build as the method expects just one
String
That's one of the major drawbacks with sticking to the Groovy DSL
And one of the major reasons I exclusively use the Kotlin DSL
Much better IDE support and type-safe build scripts
g
I'm on kotlin dsl myself but it has it's own drawbacks since ide sometimes becomes crazy with it 'cause some cache not invalidated in time
v
Should have been either
Copy code
nebulaRelease {
    releaseBranchPatterns = [/master/, /HEAD/, /OPS-14338/, /main/, /(release(-|\/))?\d+(\.\d+)?\.x/, /v?\d+\.\d+\.\d+/]
}
or
Copy code
nebulaRelease {
    addReleaseBranchPattern(/OPS-14338/)
}
I'm on kotlin dsl myself but it has it's own drawbacks since ide sometimes becomes crazy with it 'cause some cache not invalidated in time
I'm on Gradle since its pre-1.0 phase. The time I lost through Groovy shenenigans that would have saved by Kotlin DSL for me heavily outweighs the problems you sometimes have with Kotlin DSL. 😄
1
gradlephant 1
g
Yeah but using branch like OPS-14338 would be against underlying idea how to use nebula release. And likely require to redo Jenkins pipeline
👍 1
r
This is the test branch i am trying with. We generally use release branches to release new version.
g
I'm with you on that. The only case where I found groovy dsl useful for me is in init script supporting 6.1-7.x which use api like dependencyResolutionManagement, build services, exclusive content etc in one script to configure private repos to avoid creating multiple feature-dependent classes in-place.
👍 1
r
Hi All, one more question, do we have anything similar to this, anywhere did you encounter this? mvn versions:set-property -Dproperty=r4e-dependencies.version -DnewVersion=[R4E-DEPENDENCIES-VERSION-FROM-DEVELOP]
Basically i would like to update a value defined in gradle.properties using CLI. Do i need to define new task or any plugin available
v
Is this the version of a dependency you use? I wouldn't keep that in a properties file, but use the Gradle version catalogs feature. And if you use that, there are plugins that can check all your dependencies for newer versions like the
gradle-versions
plugin by Ben Manes, and also extensions that can directly update to those new versions in the TOML file containing the versions.
1
r
I am using a version catalog, i define version catalog version in gradle.properties
each time i push new release i would like to update version catalog version as well
v
Hm, well, I know of none, but I'm pretty sure some plugin out there can do it. But it should also be a very simple ad-hoc task.
r
Copy code
task setVersion(newVersionCatalogVersion)  {
    Properties props = new Properties()
    props.load(new File('gradle.properties').newDataInputStream())
    props.setProperty('r4eVersionCatalogVersion', newVersionCatalogVersion)
    props.store(propsFile.newWriter(), null)
}
I tried with above it is giving error saying newVersionCatalogVersion not found in groovy
do i need to say task setVersion(def newVersionCatalogVersion) {
v
You cannot make a task get parameters like that and if if you could, you didn't define a task action, but only configuration code that is executed in the configuration phase. And as you used eager API even always executed, whether you execute that task or not. You should read a bit in the manual about how to write tasks first.
r
Also how can i pass environment variables using gradle command line, it is not working
example: gradle jib -i -DdebianDistribution=dev -Dbuild.number=293 -Djib.httpTimeout=60000
I can't get debianDistribution
it is null always
v
get it where?
r
in build.gradle i am reading them
Copy code
def debianDistribution = System.getenv("debianDistribution") == null ? "ENV_NOTFOUND" : System.getenv("debianDistribution")
def buildNumber = System.getenv("BUILD_NUMBER") == null ? "NO_BUILDNUM" : System.getenv("BUILD_NUMBER")
println( System.getenv('debianDistribution'))
println(System.getenv('BUILD_NUMBER'))

subprojects {
    // apply plugin: "com.gorylenko.gradle-git-properties"
    apply plugin: "com.google.cloud.tools.jib"
    if (it.name.contains('-thrift')) {
        apply plugin: "org.jruyi.thrift"
    } else {
        apply plugin: "io.spring.dependency-management"
        apply plugin: "org.springframework.boot"
        apply plugin: "org.sonarqube"
    }
    jib {
        from {
            image = baseImage
        }
        to {
            image = "<http://gcr.io/rep-ops/${project.name}:${version}-|gcr.io/rep-ops/${project.name}:${version}->"+debianDistribution+"-"+buildNumber
            credHelper = 'gcr'
            tags = ['latest', project.version]
        }
        container {
            entrypoint = [
                    'sh', '-c', '/entrypoint.sh'
            ]
            ports = ['8081', '8080']
            environment = [
                    "SPRING_OUTPUT_ANSI_ENABLED": "ALWAYS",
                    "MAIN_CLASS"                : "test",
                    "DEBIAN_JAVA_OPTS"          : "test"
            ]
            mainClass = "test"
            creationTime = "USE_CURRENT_TIMESTAMP"
        }
        extraDirectories {
            paths = "$projectDir/jib"
            permissions = [
                '/entrypoint.sh': '755'
            ]
        }
        allowInsecureRegistries = false
    }
}
v
You are setting Java system properties and are reading environment variables, those have nothing in common. And actually you should probably better user Gradle properties. Besides that, just in case you are not aware. Using
subprojects { ... }
introduces project coupling and is highly discouraged in favor of using convention plugins. And
apply plugin
is legacy way to apply a plugin which should not be used in favor of
plugins { ... }
DSL.