How do I compile the project via gradle/maven?

we used same approach for java projects, via maven. whenever a branch is merged to master, it will be automatically tagged, and when building the project from jenkins the snapshot version is automatically increased.
it’s a common practice to keep the code connected with the build version in the artifact repository

To be honest, I do not understand these sentences because there contained several words undefined/ unexplained — version, manage versions automatically, node, node environment,

According to a page of JIRA document

JIRA has its own concept of “Managing versions”, which has nothing to do with Git.

I am confused which “version” you are talking about, @rajeshri.zade, — Git tag? or JIRA version?

What does he (your DevOps man) mean by saying “node”? Does he mean Node.js programming language and its runtime environment?

Your Application Under Test — is it based on Java? or on Node.js?


Your DevOps team can execute a Katalon Studio project in a Bash shell session :
https://docs.katalon.com/katalon-studio/docs/console-mode-execution.html

Your DevOps team can use any Node.js-based build tools, for example Grunt, to invoke a bash shell script, and indirectly execute a Katalon Studio project — provided that the Katalon project is pre-built (compiled) by its GUI mode into the executable format (*.class files), and all resources including the files under the <projectDir>/bin and <projectDir>/Libs directories are committed into the remote Git repository

If your DevOps team uses Grunt + Katalon’s Console Mode, then Gradle would not be needed at all.

Yeah. i was confused too. Its something like Git tag. ( we are currently tagging it manually for every release but the aim is not to do manual tagging) . I guess , it something like JIRAs version management

[quote=“kazurayam, post:25, topic:16301”]
What does he (your DevOps man) mean by saying “node”? Does he mean Node.js programming language and its runtime environment?
Devops meant Node JS

Your Application Under Test — is it based on Java? or on Node.js?
[/quote] based on Node JS

i will read the doc that you shared. seems to be helpful. Thanks.

In Managing versions | Administering Jira applications Data Center and Server 9.11 | Atlassian Documentation page, described

Add a new version

  1. The Add Version form is located at the top of the Versions screen.
  2. Enter the name for the version. The name can be:
  • simple numeric, e.g. “2.1”, or
  • complicated numeric, e.g. “2.1.3”, or
  • a word, such as the project’s internal code-name, e.g. “Memphis”.

In JIRA, the name of a version is to be typed manually. I think you can not automate it.


I have ever used JIRA extensively. In my experience, I assigned a new JIRA version usually only once or twice per 3 months while I incremented the tags in my Git repository dozens of times. My JIRA version name was nothing relevant to the Git tags — though I think it is arguable if these 2 concepts should be kept in sync or not.

The point is, I have never felt like to assign a JIRA version automatically. I do not understand why you, @rajeshri.zade, if I am right, say like to automatically assign names to JIRA versions .

I do not see why you aim not to do manual tagging.

As you know, Git assigns “Commit Id” automatically for every commits. Isn’t it enough? Why you want more of automation?


  • You (testing team) already have a Git repository of your Katalon Studio project, right?
  • You already have several Git branches, right? master, develop, featureX, featureY …
  • Let me assume that you (testing team) are currently working on the develop branch of your KS project repository.
  • Git has a concept of head. head is a named reference to the commit at the tip of a branch.
  • Your DevOps team wrote: “we need some thing that can increase and manage versions automatically, not by modifying a text file manually" — I do not understand what he means. Or, I would disagree, you do not have to worry about managing versions automatically. Git commit-id + HEAD solves everything.
  • You can tell Git that you want to use the current slice of the develop branch by specifying “I want the head”. You do not have to write the commit-id (e.g, 3fae440c7011d5f6e6f7103bea4f7d385fc041de) of the last commit in a text file manually.
  • You use simply git pull; git checkout HEAD develop. You can obtain all of commits performed into the develop branch in the Remote Git repository. Usually you would need “all commits”. You would rarely (or never) want to go back to a specific commit-id of your develop branch.

quoting from Learn versions with Jira Software | Atlassian

WHAT IS A VERSION IN JIRA SOFTWARE?
In Jira Software, versions represent points-in-time for a project. They help you organize your work by giving you milestones to aim for. You can assign issues in your project to a specific version, and organize your sprints around completing work in that version.

Please note, a JIRA version is a name allocated to a bunch of JIRA issues. JIRA’s version has no immediate relevance to the tags controlled by Source Code Version Control System such as Git.

For example, my previous JIRA project had the following names of “version”:

  1. NextRelease
  2. 2ndNext
  3. Future
  4. NoPlan

All of outstanding JIRA issues (tickets) were categorized into one of the above 4 “versions”. These categories meant the priority for resolution. The project owner (=me) quite often reviewed each individual issues and moved them from NextRelease to 2ndNext or from Future to NexRelease etc.

Of course, I also had a list of version names such as 1.0, 1.1, and 2.0.1. These were created just for recording purpose of previous releases which had been already done. When a software version of NextRelease was actually released, I added a version x.x.x, which is relevant to the tag of Git, and I moved all JIRA issues in the NextRelease into the new x.x.x version. It was a sort of house-keeping type of work. If I select the 2.0.1 version for example, I could see the list of JIRA Issues which had been resolved at this releases; the list was quite useful for looking back the project’s history. That was the way how I utilized JIRA’s versioning feature. Please note I manged JIRA versions just manually. I never felt like to automate numbering JIRA versions.

I am talking about something off topic. This comment is not relevant to Katalon products at all. I should stop this.