Is it possible to have multiple projects within a single GIT repo using the Git integration plugin? It seems at the moment that it expects a single project at the root level of the repo. This is not very elegant as we need to spin up a new repo for each unique project whereas it would suit much better to be able to have multiple projects in a single repo (likely partitioned by folders at the root level).
Also, it is possible to add a project from ready api to an existing repo without replacing the content already existing in the master?
At the moment, we've reverted to using GIT outside of ready API which adds additional steps/risks to the cycle.
You've likely figured this out by now, but so that others can see the answer if they're searching.
I had the same questions, and since your question wasn't answered, I put a help ticket in with SmartBear to find out.
Here is their answer:
Currently the git plugin does not support multiple projects in a single repo. A feature request was created for another user so I will make sure that your request is also added to it to increase visibility.
You cannot put the project in a repo with other projects in it. You will be prompted choose whether to merge them. It is recommended that you put the project as root of an empty repo.
Looks like for now, if we want separate SoapUI projects in the same repo, we have to handle Git management outside of Ready API.
For what it's worth, I originally started with all of my SoapUI projects contained within the same project within GIT. At first, this made it really easy as I was the only one on the Test team, and it made sense. I was the source of truth and it made it a lot easier for me to just commit my work for the day once, instead of for 30 different projects.
Ultimately, it came to be one of the worst things I did. Developers had a hard time pulling down my projects due to how large they were. They didn't want everything, they just wanted the project for their service.
I ended up breaking every project out into individual git repositories and it was better, overall. It allowed for more flexibility and upkeep. There was a little more overhead, and I had to keep better track of how I committed, but in the end it ended up being much cleaner and straight forward to deal with. Not only for the developers, but for myself as well.
Thanks for the response. Please keep me posted with any developments on the feature request.
Thanks for the response.
I see a big difference in having multiple projects versus multiple GIT repos. Agree that a test project should be kept as succinct as possible but we really should not be limited from having multiple independent projects in a single GIT repo.
From a .NET perspective, you can have multiple independent solutions in a GIT repo, developers simply pull down the solution they are interested in working on and do not need to worry about other solutions within the repo.
Having multiple repo's is a real nightmare when it comes to CI/CD. I want our test projects to live in the same repo as our actual APIs and have our CI/CD DTAP specifies as branches in the repo (feature specific, TST, Staging, PRD). When CI is running it can then deploy the APIs to the relevant target then on a separate task, pull the relevant test project associate to the API and execute the tests etc.
Having to jump to different repos is a real pain and it also does not keep control in the Continuous Delivery pipeline. At least IMO this is sub optimal and leads to much more overheads of trying to keep different repos in sync (e.g. the actual API delivery code and the related API test suites)
I'm faced with the same issue, currently. Is there any way to track the feature request? I have just moved our project into a git repository, and I'm disappointed to find the project cannot exist within a folder at the root level.