- Jun 17, 2020
-
-
Georges Racinet authored
A side benefit of `--doctest-modules` is that it will import all Python modules (looking for doctests in them), and by doing so, it will find missing `__init__.py` files and other inconsistent imports.
-
Georges Racinet authored
It seems that many streaming Gitaly responses are actually streaming responses which themselves contains chunks of content. An example would be `RefService.FindAllBranchNames`. Couldn't find anything really convincing in `itertools` for that.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
and as always, if it ain't tested, it ain't working.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The previous way to create a topic changeset simply did not work, revealed by switch to testhelpers topics facilities from py-heptapod: the call to `FindCommit` was also done for the wrong GitLab branch! Taking into account a small trap: the config set on the wrapper is transient (akin to command line arguments), therefore it doesn't apply on the HGitaly server side.
-
Georges Racinet authored
-
Georges Racinet authored
In current GitLab, setting the default branch from the Rails app is done by the `Project` model, which in turn does: repository.raw_repository.write_ref('HEAD', "refs/heads/#{branch}") and write_ref is provided by RepositoryService
-
- Jun 16, 2020
-
-
Georges Racinet authored
this is where reading the default branch is implemented.
-
- Jun 17, 2020
-
-
Georges Racinet authored
Doing that before we accumulate more source files. It didn't feel right for the stubs: not only is this generated code, but also does it come from source (proto files) onto which we have no copyright. Same for placeholders like __init__.py for namespace packages: that's not really of our doing.
-
Georges Racinet authored
With py-heptapod supporting both Python 2 and 3, not so much was left to make HGitaly tests use its test helpers directly, ending this de facto fork. This is also a first use case for the CI running against the head of py-heptapod default branch.
-
Georges Racinet authored
It's becoming pretty clear that we'll have a fair amount of code to share between HGitaly and py-heptapod, for instance anything that involves GitLab branch conventions. In that context, developping HGitaly against released versions of py-heptapod would strongly undermine our velocity, at least for a while. The py-heptapod repo is small enough that a full clone from foss.h.n is not a problem (and Heptapod Workhorse is on our side these days). We could later on preclone in the base Docker image, though.
-
- Jun 16, 2020
-
-
Georges Racinet authored
Keeping what's expected to be shared by all HGitaly services in the `HGitalyServicer` mixin class.
-
Georges Racinet authored
The `grpc_add_to_server` and `grpc_servicer` fixtures were just conveniences to feed the final server fixture, `grpc_server`, that we can redefine without so much duplication (most of the job is done in the definition of the lower level `_grpc_server`). At the other side of the spectrum, `grpc_stub_cls` was just a convenience to feed the actual `grpc_stub`. Again most of the job is just done in `grpc_channel` (that depends on `grpc_server` so that something is actually listening), and we just use `grpc_channel` and instantiate the stub to get a working client on our test class. In the end, we'll be able to add more servicers to `grpc_server`, and each test will use the appropriate stubs: tests depending on several services will simply use several stubs on a single channel.
-
Georges Racinet authored
The reading is done by `RefService` whereas the setting is done by `RepositoryService`, in `WriteRef`.
-
Georges Racinet authored
`lint.proto` is a new dependency among them. Still the same problem with imports that have to be converted to relative style.
-
Georges Racinet authored
The proto files are now versioned with Gitaly itself. Also it seems that the Gitaly server version is identical to the GitLab version, but we should always check.
-
Georges Racinet authored
Hoping it'll give us the very fast build we yearn for.
-
Georges Racinet authored
Same as in most other CI configurations: failing on the head of Mercurial default branch should not be a blocker.
-
Georges Racinet authored
This is a nice example of how a guess based on the type of an argument can be wrong. First tries with actual GitLab client showed that this revision is called "id_or_ref" on the client side, and can be either - a SHA ("id") - a GitLab branch name ("ref") - HEAD, meaning the head of the default branch, not supported yet in HGitaly. Just hoping there's not more advanced syntax such as `master~3` that would force us to do a full conversion from Git revspec to Mercurial revset syntax.
-
Georges Racinet authored
Up to now, we didn't declare any requirement in setup.py. We're adopting here a three-layered structure, with the full blown `dev-requirements.txt` carrying the needed tools to recompile the gRPC stubs. grpcio and grpcio-tools can be heavy to install, especially in CI context. We still have the problem that heptapod will pull Mercurial, just hoping it wouldn't mask the stable and default Mercurial versions.
-
Georges Racinet authored
The command can be launched as `hg hgitaly-serve`. Being actually a Mercurial command means it has its help page, generated from the docstring and command-line options declaration. We've made some effort to support Python 2 in the command, but currently the actual servicer code is Python 3 only, because of type annotations.
-
- Jan 09, 2020
-
-
Georges Racinet authored
We use the `pytest-grpc` helpers. This implements only the `FindCommit` RPC call, but in a complete manner. This raises several questions: - for now, we have a single `servicer` module, but Gitaly has many services: How shall we organize our code? - the fixtures for gRPC server have the module scope. Shall we have such a fixture for each service? - will we be able to create commits directly with the Gitaly API in the future? - do we want to separate the tests in several layers, ie those that don't need a gRPC server (unit-testing the `changectx_to` functions) and those that do?
-
Georges Racinet authored
commit.proto uses in turn `shared.proto` Actutally had to change the imports between these modules to the explicit relative style. That will have to be improved. Also should commit a Makefile to do this for all protos. The generated Python code should not go anywhere near a linter
-
Georges Racinet authored
Passing the `username` with `ui.config` just does not work because of the cascade of defaulting in context instantiation. It's simpler to just make a new kwarg out of it, and one more occasion to make life simpler by accepting plain `str`. Name for the `user` kwarg is in accordance with the method on the resulting changectx. The `utc_timestamp` is named to be very specific. In tests we should not need to worry with anything more complicated. This would probably not be acceptable for a general purpose library.
-
Georges Racinet authored
The versions of gitaly-proto and the gitaly server used in GitLab are not the same. In Heptapod 0.8 (based on GitLab 10.5.8), we have GITALY_VERSION=0.81.0 In turn, in gitaly 0.81.0, gitaly-proto is vendored at vendor/gitlab.com/gitlab-org/gitaly-proto, where we can see that go/VERSION is 0.84.0
-
- Jun 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
As done previously for py-heptapod, the latency of a separate lint stage is not justified. However lint+tests on a precompiled Mercurial version is much faster, and that justifies to push the 'stable' and 'default' Mercurial versions to a `compat` stage.
-
Georges Racinet authored
Using the ci-py-heptapod image is a simple choice to run tests with the currently supported Mercurial version, obviously the same as with py-heptapod. pytest and pytest-cov are now provided by all the base images. Doing the same initialisation for hg stable and hg default versions as in py-heptapod.
-
Georges Racinet authored
Even though that feels somewhat redundant, it's less awkward than having a hgitaly package next to a hgext3rd.gitaly one.
-
- Jan 09, 2020
-
-
Georges Racinet authored
We're running tests against latest released Mercurial versions and the heads of the stable and default branches.
-
Georges Racinet authored
We reach back 100% coverage of the testhelpers module itself.
-
- Jan 08, 2020
-
-
Georges Racinet authored
Extracted from the `py-heptapod` project and converted to Python3. These should be on PyPI, really (naming suggestions welcome). These helpers circumvent some of the bytes/string awkwardiness in Mercurial, up to a point: once we get a native Mercurial object, it's natural that for instance its description is bytes. That doesn't mean we have to pass config section names as bytes, though (but one could).
-
Georges Racinet authored
we will have a `gitaly` Mercurial extension, but that should be just a thin registration layer for our command. Most of the code will be in the `hgitaly` package, for maximum flexibility and future proofing in case we really to evade from the extension thing.
-
Georges Racinet authored
-