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
- The Add Version form is located at the top of the Versions screen.
- 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 thedevelop
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 yourdevelop
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”:
- NextRelease
- 2ndNext
- Future
- 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.