I have a git repo "core" and "project" repo, that is using "core" as dependency. If I want to change some API of "core" module, and its usages in "project", I create two separate pull requests in gitlab. But our continuous integration system can't test "project" until "core" will be merged, if "core" contains API changes. What I want, is the possibility of "project" test will go on the same branch in "core". For example if I created branches "feature-42" in "project" and "core", the "project" tests will start on the "feature-42" branch of "core".
Now we have an opportunity to move at go modules, but it is hard to always specify the direct commit hash in go.mod file(many possibilities to made a mistake). It looks like we should use monorepo, but I scared of the possibility our project will become monolith (considering that we have not very qualified developers).
How can we organize our continuous integration?
P.S. also we don't wanna use tags with version, because people works in parallel, and it is hard to maintain always non-decreasing versions.