- 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
-
Georges Racinet authored
This allows to serve directly with, e.g., gunicorn heptapod.wsgi:application This is taken from https://dev.heptapod.net/heptapod/heptapod, in config/mercurial with the following modifications: - in advance for heptapod#73, we'll forward headers for User and Project Id - we don't need a specific configuration file, we're including the instance-wide `heptapod.hgrc` (same as heptapod!35 does for the current stable branch)
-
- Nov 07, 2019
-
-
Georges Racinet authored
This is based on hgwebdir_mod but doesn't need any scan of repositories. Needs some cleaning and testing (notably for future Python3 versions) Should eventually absorb the WSGI wrapper that's currently shipping in config/mercurial within the Rails application.
-
Georges Racinet authored
will enclose everything except the upcoming heptapod extension.
-
Georges Racinet authored
-