Want to understand whether robotframework has any library\libraries that can handle the following case.
My test cases are part of Gitlab and as part of git pipeline, want to run the tests on a secured remote server in different network and push the results back to Gitlab. Opening firewall to initiate the trigger from cloud is considered as not secure. Framework has SSH, Telnet or remoterunner capabilities but cant use those as not acceptable in my case.
Anyone has any better solution to handle this kind of scenario.
Something like putting message in que, which is in cloud and some kind of agent in remote server that always monitors que and does the job as per message. OR
is there any secured way of connecting the server to run the tests?
I don’t see why you need a specific library to acheive this? You can do this with standard git commands.
In the repo that contains the test cases, first create a folder to store the test results.
On your “secured remote server” that runs the tests
- git clone the repo that contains the test cases
- checkout the branch you are running the test for
- create a branch that represents the build name and and other things that make the test unique and then switch to this branch
- create a folder in the results folder (see above) that’s unique to the test results
- run robot framework redirecting the output directory (-d or --outputdir) to this newly created results folder
- check in the changes to the contents of this newly created results folder (ignore changes outside the results folder)
- push the commit back to the git server
- (optional) merge the new branch created above back into the branch you are running the test for
I do a similar process for rfswarm with Github workflow runners,
- I have a condition to only do the later check in push and merge steps if the test case fails
- As i run multiple tests based on component, os, and python version I use this to create the branch and folder names, e.g.
- agent-macos-3.8 (componet-OSName-PythonVersion)
Github has prebuilt actions for git commands, perhaps Gitlab also does?
I realise this is quite high level and not specific commands but it should give you the concept.
Thank you so much for the reply. We kind of looked at this possibility. In our case, we also want to see the pipeline progress or execution progress within cloud pipeline(not the pipeline part of secured remote server). Cloud Pipeline common for all other services or programs, and we also want to use the same pipeline to run tests on remote server. May be we can use different runner configuration in the cloud with some script/commands to do this job. Hope I am clear. May be this is little different use case.
I’m not sure I understood your reply?
- You have a Gitlab repository, (internal or Gitlab hosted, it doesn’t really matter)
- You have some cloud pipeline runners
- You have a (some?) secured remote server(s) that are also pipeline runners
You can have different runner configuration’s if you want them to do different things (one checks in results and the other doesn’t)
Or you can have the same runner configuration if you want them to do the same things, (all check in results, or none check in results)
Really it’s just a small change to the runner configuration to do the extra steps of create the branch, folder and then check in the results so you could just make a copy of your original configuration and modify it, or maybe if you can do some kind of configuration import you can import your original configuration as a subsection of the new one that does the extra steps for ease of maintenance.
Hopefully I understood you correctly?
In our case, Gitlab hosted, Gitlab Agent and Runner(deployed by Agent) is part of EKS Clusternamspace. This is common Infra for all programs and all are part of Cloud.
There are programs, who want to use the same Infra to run the tests on remote server(in different network).
Configuration can be changed but same Gitlab and Agent needs to be used.
Remote Server is not part of the cloud and can be Windows or Linux or Ubuntu machine.
Hi @naveens ,
OK so it’s quite similar to what I expected, so what I proposed should work as the runners only need to have access to the hosted gitlab, which they already do, to download the test cases, the git push command is what would upload the results.
You could have the same configuration regardless where the runner is, it just means all runners will upload their results to gitlab, this would be good from a consistency standpoint, all the results are in the same place.
But there may be a reason why you might not want that (security complaining about internal IP addresses being leaked outside the network or something like that?), in which case then you’ll need a different runner configuration, but it would only be different in the sense that it would perform a different sequence of steps, everything else should be the same.
I hope that’s clear, unfortunately I’ve not used Gitlab runners so I can’t give you specific examples.