Hi,
Why “Katalon Standalone Edition” does not have “Git > Clone Project” option?
I ask because I need to access a local repository, not accessible in Katalon TestOps.
Tks!
Hi,
Why “Katalon Standalone Edition” does not have “Git > Clone Project” option?
I ask because I need to access a local repository, not accessible in Katalon TestOps.
Tks!
Hi @sone.anderson,
Welcome to Katalon Community!
Could you tell us which version of Katalon Studio you’re using? And also which OS you’re using it on as well?
If possible, can you check the upper-left corner of your Studio interface? There should be a Git button there that will allow you to clone your project to your local machine.
If in case you don’t see it, or it is greyed out, please go to Preferences > Katalon > Git, and check the box “Enable Git Integration”, then click Apply and Close.
Please refer to the below link for more information:
Let us know if this helps!
Hi, @albert.vu
I’m sorry, I made a mistake…
The correct is: I’m using “Platform Edition” on Windows 11.
And my GitLab Repository is on my company intranet, not externally accessible.
and how do you expect a www (cloud) resource to be able to reach a private resource?
by magik?
@bionel u r so funny! Here is a forum, and the people has question…
So…
My question is why the configuration cannot be done at client side.
And I didn’t find any explanation of differences between Platform vs Standalone.
tks
platform == cloud == www
standalone… mhm, should i say more?
why do you think, working in a private resource/network, the cloud platform will be able to reach it?
do you guys working in testing various web apps, have basic knowledge about networking?
@albert.vu
@vu.tran
@Elly_Tran
I have a question to Katalon team.
In the document
I found a description
Upload test scripts from a Git repository
- You have an existing test project in Azure Repos / Bitbucket / GitHub / GitLab / AWS CodeCommit.
This description is not clear enough to me. We have 2 cases where
Does Katalon Studio Platform Edition support both cases?
Is it possible for a user to use Platform Edtion using his private GitLab?
Is it possible for a user to use Platform Edition using his private GitHub Enterprise server on his intranet?
I ask this to Katalon team because I only use v8.3.0, so that I don’t know anything about v8.5.0 Platform Edition.
I ask this because I suppose I would not be able use my private Git repository hosting server in Katalon Studio Platform Editon.
I ask this because Katalon’s documation is not clear enough about the case where user’s Git repository hosting server is on their private network.
I guess that Katalon team strategically ignored (somebody tell me better english please) the users who are capable to build&maintain their testing infrastructure for themselves. Katalon wants to promote their TestOps product which is forcused to serve users who are unable to build&maintain the infrastructure for themselves.
To me it seems that Katalon Team is reluctant to write “you can not use your private GitHub Enterprise server with TestOps, therefore Platform Edition is not good fit for you” in the documentation, as this sounds bad for marketing.
Am I wrong or right? Please clarify.
I believe that this umbiguity confuses many people.
Hi @sone.anderson,
Can you try whitelisting the Katalon’s domains to see if TestOps can connect with your GitLab repo? Please see the below doc for more information:
Let us know if this helps. Thanks
How is this supposed to work?
Let’s say, I have my Gitlab on-prem installed on a certain internal datacenter, behind the company firewall, having the DNS like gitlab.mydomain.com
.
The DNS is handled by the company DNS services, also behind the firewall.
From the company intranet I may be able to reach www, but from www I am not able to reach intranet resources (obviously why) without connecting my VPN client.
So, even if (by luck) the IT team agrees to “whitelist” the needed Katalon domains for out-going traffic (provided are blocked), how the requests (incoming traffic) from www (where TestOps resides) are handled ?
How the DNS will be resolved to point to my on-prem resource?
How TestOps will tunnel to my intranet without knowing what VPN client / server is in place?
(just my two cents, theese applies for both @sone.anderson and @kazurayam questions)
I am afraid that this sentence reveals that @albert.vu does not appreciate the significance of security concerns for serious enterprises appropriately.
“Whitelisting” is not something we, Katalon users, can try casually.
If an employee who has a private Git repository wants to try whitelisting, he/she must convice the companies’ network administrators and the high-level managements (CTO) as it matters (breaks) their current security policy. I am sure that it will be quite tough to lay the groundwork. If he/she tried whitelisting TestOps without authorization, will be fired.
This suggestion implies that Katalon requests us to turn our private GitLab to public = exposed to the Internet so that it is accessible for TestOps.
Am I wrong or right?
I think it is OK if users must choose either of the following:
or
If Katalon explains this clearly, the users who have a private Git respository on their companies’ private network will think and decide.
Think so. We need a better explanation of what “whitelist” means in this context.
Grabbing popcorn …
Exactly. That is why I had to abandone TestOps and all it’s functions and possible advantages from our world. At least we are saving money on the subscription.
please stop using this term until we get a fully explanation
whitelist it is usually used in the context of outgoing traffic. which is not solving anything imho.
what seems to be actually needed is to fully expose a private resource to www for incoming requests.
such is not trivial to achieve for a single internal resource paired to a single external domain and any sane it team will reject such abominating idea. period
OK. I will use this term here for the last time, and will stop.
Browserstack documentation gives us a description of their term “Inbound IP Whitelisting”. I assume that @albert.vu has something similar in his mind.
If applied, TestOps must publish its static IP addresses to be listed by users, which must be maintained for its lifetime; no DNS to be used.
Publishing its static IP address would cause serious difficulties to the TestOps service itself. Katalon can never change the IP address. They would need Elastic IP provided by AWS or something like that, and keep the address unchanged forever. If I were the admin of TestOps, I would ban the idea.
Most probably. I wish luck with this.
In addition to some more data needed from TestOps side (clear list of ip:port pairs) , this involve some effort at org level also (company side) to be sure only what is needed and only for what is needed is … mhm, ok, ‘’ whitelisted".
And this it is also highly dependant on the firewall solution used and the internal network configuration company side.
And usually, this will involve a security assesment from the company side, since, most probably, the company policy is ‘zero-trust level’.
I agree with you.
I suppose the intention is to achieve such via the Tunnel feature which is (poorly) documented here:
But I still cannot see how:
Another thing I don’t understand is
… looks like, in TestOps, actually we don’t set a git repository (so the code is pulled at the moment of running the tests from the company git) but we upload it one time and further the development should happen on the repository from TestOps.
Which makes the code to be public actually since is no longer hosted on a private resource but on TestOps.
Which, again, may infrige the company policies …
I suppose, those enterprise with “zero-trust level” policy would never be interested in TestOps which effectively violates their policy. So, it is pointless to discuss about “Incoming IP whitelisting” for TestOps.
I suppose Katalon Team would be able to strategically concentrate their development efforts to the potential users who have relaxed security policies and public Git hostings.
That is also my opinion.
So, for such cases, using Standalone edition and company own CI environment is the only option, IMHO.