HGitalyServicer: loading repository for mutation
The `HGitalyServicer` base class now provides a `for_mutation_by` optional argument that triggers the setting of all needed repository config items and environment variables as already in use when spawning Mercurial subprocesses from the Rails application: repository mode (nativity, with Git mirroring or not), link to MR to allow distinguishing between merge permissions and direct pushes, etc. The acting user is part of the request message in all examples we have considered so far, hence passed down by the caller (concrete service subclass). Other metadata are expected as invocation metadata (hence HTTP/2 headers, which matches what also happens between Workhorse and the Rails aplication). We had to add invocation metadata handling to the `FakeContext` to maintain coverage. The import path from `grpc` is probably instable, but we'll live with it. WIP implement UserSquash, with Git mirroring or not Needs lint to be ok, coverage to be 100%, a decision about itering on invocation metadata so much. The breakthrough is that HGitaly is able to control internal Git mirroring and this can be tested from HGitaly (ordinary) integration tests. At this point this does not implement passing of user information to internal API (can only be tested from functional tests, as it requires a fully working Heptapod instance). The `UserSquash` method in itself was only chosen because it does not have many options and is at its core very simple to implement. WIP to fold: refactoring putting mutation metadata in repo config/environ WIP first version working in functional tests WIP some linting (grpc import in tests will be used later) WIP added tests with Gitaly Almost complete (for_mr_iid missing) except coverage when skipping Gitaly Comparison accept_mr_iid Full coverage for UserSquash
parent
6f9ca3f8
No related branches found
No related tags found
Loading
Please register or sign in to comment