- Dec 15, 2019
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
This will be help bootsrapping developer environments. Apparently it's now deprecated to run tests with `setup.py test`, so we don't bother listing it in setup.py.
-
- Dec 14, 2019
-
-
Georges Racinet authored
This is about as much we can test without using a WSGI request object (fake or real)
-
Georges Racinet authored
For now this is testing of current behaviour, keeping note of a potential security tightening (not a hole because HgServe is always invoked from localhost with the Heptapod headers, but it would be better to stay secure if it accidentally were to respond on public interfaces)
-
Georges Racinet authored
this will be more direct for unit tests. Also we did not need to store its path. More tests will demonstrate that.
-
Georges Racinet authored
we now have a proper Mercurial extension and it declares that configuration item
-
Georges Racinet authored
This depends onto heptapod-docker!5, which sets said environment variable. This still allows us to run in a gunicorn one-liner without any further wrapper, while being less hardcoded and unit-testable, as the first test demonstrates. It would be even nicer to instantiate `HgServe` without any configuration file (relying e.g. on baseui to pass configuration), this could be done later.
-
- Dec 13, 2019
-
-
Georges Racinet authored
-
- Dec 14, 2019
-
-
Georges Racinet authored
This gives a 100% coverage on this module for me
-
- Dec 13, 2019
-
-
Georges Racinet authored
in our cases, failures depend whether other extensions, such as evolve or hg-git are themselves ready for Mercurial default. Currently we do have a test in a topic that's broken because evolve 9.2.1 is not compatible with Mercurial default. We will of course change the build to use evolve default, but it's not guaranteed to work, and even so, that may break later on. We don't want to stall our development for this.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
no need to run against all versions if linter rejects changes. This is mostly to play with GitLab CI, py-heptapod tests are currently fast enough that's not much of an issue.
-
Georges Racinet authored
and it makes sense to factorize a bit, mostly stuff that should be in the base image.
-
Georges Racinet authored
it will be useless to run that agains several Mercurial versions
-
Georges Racinet authored
Up to now, we've been testing with the system global one, which turns out to be Mercurial 5.2
-
- Dec 11, 2019
-
-
Georges Racinet authored
This had to be rewritten after the hook itself has been moved from hg-git to here. It's a good occasion to do it with our test helpers. We now have 100% coverage for this hooks submodule
-
- Dec 03, 2019
-
-
Georges Racinet authored
This is so we don't forget to convert it to the appropriate testing system.
-
- Dec 13, 2019
-
-
Georges Racinet authored
It's probably what we always want if we care about the return, will maybe become the default later. Tested by using it in test_write_commit_random()
-
Georges Racinet authored
That should help users focus a bit more on topology, at a negligible price in speed. The content really has to be random, to make sure there is something to commit.
-
- Dec 11, 2019
-
-
Georges Racinet authored
It seems that the high level command in the `commands` module is the one taking care of locks etc, so maybe it's better to go through it. We rewrap it in the way that's more usable than being forced to provide a kwarg for each phase, hence the name `set_phase()`
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
and demonstrating them in tests. Checked also that hgrc is properly read in LocalRepoWrapper.load()
-
Georges Racinet authored
-
Georges Racinet authored
The idea is to provide what's needed for efficient Mercurial tests at lower level than the .t system (text-based tests), yet still more integration than pure unit. By not spawning hg processes, it should be faster than text-based tests. Calling in the inner API will allow tests that are closer in style to main developments being tested, while simplifying assertions. This version is meant for python2 only for the time being, because that's what is currently to be tested for Heptapod. We'll convert it for py3 for the hgitaly project, or make it agnostic and publish it independently in some or other way.
-
- Dec 13, 2019
-
-
Georges Racinet authored
branch/ was missing. Was using a wrong URI in doc from our current rails app, but it's correct in the embedded settings page
-
Georges Racinet authored
For now, for the heptapod-0-7 branch because that's where we are setting it up. Will have to switch to default of course once merged therein.
-
Georges Racinet authored
-
Georges Racinet authored
-
- Dec 11, 2019
-
-
Georges Racinet authored
-
- Dec 02, 2019
-
-
Georges Racinet authored
they've been taken from Heptapod fork of hg-git (https://dev.heptapod.net/heptapod/hg-git) at revision 0b4f514018a6.
-
- Dec 01, 2019
-
-
Georges Racinet authored
This follows the plans of heptapod#127, we don't need to label it as `stable` any more. It's a release branch, it becomes the stable naturally.
-
- Nov 24, 2019
-
-
Georges Racinet authored
It can be useful for certain operations launched from the Rails app itself.
-
- Nov 23, 2019
-
-
Georges Racinet authored
This will allow Heptapod to nofity GitLab directly when appropriate, see heptapod#73
-
Georges Racinet authored
-
Georges Racinet authored
-
- Nov 16, 2019
-
-
Georges Racinet authored
so now, it can be launched with gunicorn heptapod.wsgi:hgserve Who knows? We might at some point need another WSGI application.
-
Georges Racinet authored
It doesn't need to be separate now that it's in the same Python module as the supporting class
-