I have the impression that this is a 101 question about GitHub actions, but it really made me think a lot... I have always heard that it is best practice to have a repository apart from the main source so the QA team can create the end to end tests and some integration tests. But if there is a repository with the testing and a repository with the main source of the software, how will one grab the tests from a project to run in another?
"I have always heard that it is best practice to have a repository apart from the main source so the QA team can create the end to end tests and some integration tests."
I suggest examining this assumption. I think it is best practice to have all the code in one place. I encourage both groups to contribute to and run the tests. Having them in one place encourages this. Having them in separate places encourages tribalism and finger-pointing and second class citizen issues in my experience over the last 20 years in both dev and quality positions.
Generally this reflect the move from QA as 'post development verification' to 'development partners'. Many organizations struggle with this and in addition their current staff is not set up for this new way of working.
It is hard to integrate QA with development for agile development. It is often much easier to have QA be a separate group and to justify this for a number of reasons (independence, regulation, different mindset for testing, etc). However over time I have observed that the separation leads to poor quality and two teams often at odds with each other. Human tribalism frequently takes over.
The assumption may also reflect practices and workplaces before Agile became mainstream. Many organizations continue older behavior because no one is telling them (would be 'guiding them' if they were agile) to change and their business was successful in the past. Inertia is strong in these situations and change is often hard at first.
If you don't have this choice and have to live with the two repos then testing would mean
- clone both repos
- configure the testing repo to use the app repo.
However you'll quickly run into coordination problems with this approach in my experience.
I have a large number of projects on github and I use github actions and this hasn't been an issue because tests are in a test/ directory. Complications may arise however when you need to use application code from multiple repositories.
If you're talking specifically about GitHub Actions, then you'd need to use repository_dispatch for that. That basically means you need to call a certain endpoint (more info here) in order to trigger a workflow (in your test repository) in a repository by something that happens outside the repository (repository with the main source code of the app as you mentioned).
In different CI/CD automation services, the whole approach might be a little bit different. E.g. in Azure DevOps, you can build an app and your test code (if you need to compile it) in build pipelines, they could be in their separate repositories, and then pull all necessary artifacts into a release pipeline and define steps you need with all these artifacts you have now available. So, if you're talking about an integration or end-to-end automation, this could be an approach to go for.