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.
Your go.mod file can specify an explicit commit of a dependency — even if that commit is on a branch! — as long as the commit has actually been published to that repository.
So if you publish a feature on the feature-42 branch of core and want to use that in project, you can run go get core@feature-42 within the project module and you should get a version that includes that feature.
(The go command knows how to resolve a branch name to a specific commit in general, so you shouldn't need to name the commit hash explicitly. However, the go.mod file will record a pseudo-version with the resolved hash.)
As another alternative, you could add a go mod edit -replace command to your CI system, to have it explicitly replace the selected version of the core module with the branch in question.
All that said, it sounds like it would probably be simpler for you to switch to a monorepo, perhaps with a single go.mod file at the repo root so that everything is versioned in lock-step. In my experience, the best way to avoid a Go project turning into a monolith is through the use of internal packages, not separate repositories.