- Mar 09, 2020
-
-
Georges Racinet authored
This is done by subclassing `GitHandler`, for now adding `update_exportable_for_named_branches`, almost identically. The only functional difference is that named branches and topics are always exported, i.e., not depending on the value of `hg-git.export-named-branches`
-
- Mar 12, 2020
-
-
Georges Racinet authored
since this works by changing the target repo, this is the most convenient way for end users.
-
Georges Racinet authored
-
Georges Racinet authored
with the upcoming addition of more pytest options, it becomes somewhat necessary to have a single script to avoid duplication in the CI config and some pain for developers. run-all-tests passes all subsequent arguments, allowing to add, e.g., HTML coverage generation options and the like.
-
- Mar 09, 2020
-
-
Georges Racinet authored
The tests are fast enough that a separate lint stage is overkill (it was mostly to try the stage system). However, having compatibility onto future Mercurial and Evolve versions in a second stage is meaningful: these are quite heavier because the dependencies can't be prebuilt, and it doesn't make sense to run them if the main tests don't pass. Install check is also on this second stage, that's again a job that's not expected to fail often but is somewhat heavier, without the dependencies provided by the `ci-py-heptapod` image
-
Georges Racinet authored
we don't want to simply `install .` in the before_script because we want to install precise Mercurial and hg-evolve versions first. Also, typically, the current head of hg-git is required to work with Mercurial stable or default.
-
- Mar 11, 2020
-
-
Georges Racinet authored
Besides being handy, it's necessary to set a topic while using `parent`. Indeed the inner update can void or change the topic, so that calling the `topics` command before hand is not sufficient.
-
Georges Racinet authored
with the command not taking care of iterables not necessarily been lists and assuming it's called from the CLI, it's a real pain without such rewrapping.
-
- Mar 08, 2020
-
-
Georges Racinet authored
as we're about to add more functionality to the `heptapod` Mercurial extension, we'll need to start organizing a bit more
-
Georges Racinet authored
Specifying the path to `__init__.py` as we previously did makes Mercurial import it as a standalone module, even if it is available for regular import as a package. In turn, this prevents relative imports, as we'd like to introduce to actually start splitting it.
-
Georges Racinet authored
In may cases, `ui.environ` is simply `os.environ`, which obviously causes side effect issues between tests. One of these is that check_write was wrong: if no user is provided, then permission should be granted.
-
Georges Racinet authored
All the remaing tests are in test_pull_force_topic and identical alreay.
-
Georges Racinet authored
test_already_obsolete was in the accidentally duplicated test_import_force_topic, now it's in test_pull_force_topic
-
Georges Racinet authored
The one from test_pull_force_topic was identical, except it had an additional assertion (pull-force-topic return code)
-
Georges Racinet authored
the one from test_pull_force_topic is more interesting, as it matches more closely the practical case (revision already pulled, not remote empty repo)
-
- Feb 19, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Feb 15, 2020
-
-
Georges Racinet authored
These will be exposed first through the REST API (this is heptapod#165), then we'll probably want them to be displayed and writeable from the Web UI. Compared to the lower level versions, they have several advantages: - clearer namings: the lower level knobs have names that are make sense independently of the context, but in Heptapod, we can make more assumptions about the context, and hence come up with something more immmediately meaningful to users - easier to remember, less frightening (it's not more experimental than Heptapod itself) - several flags can be set at once (see the case of bookmarks) For now, the rule is that they are really inert if not set, so that we don't interfere with tweakings of the lower level settings our users may already have performed. It's also the occasion to introduce `auto-publish=all`, which makes a project entirely publishing - can be the preferred way for some.
-
Georges Racinet authored
This tests the patch of `ui._runsystem` that forwards environment variables to external hooks
-
Georges Racinet authored
reducing duplication is always good. In this case it makes the config of each test clearer.
-
Georges Racinet authored
One less thing to tweak when we switch to Python 3
-
- Feb 05, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 30, 2020
-
-
Georges Racinet authored
This is needed in particular so that they are in Heptapod backups
-
Georges Racinet authored
Currently that's also 5.3rc1, should diverge to be a 5.4 dev version soon.
-
Georges Racinet authored
hg-evolve 9.2.1 is simply not compatible with hg 5.3rc1 anymore
-
- Jan 23, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 21, 2020
-
-
Georges Racinet authored
This is necessary for heptapod#169: the caller needs a clear indication that the pull was empty. The choice of return code is consistent with `push` exiting also in code 1 if there is no changeset to push (but still pushing phase changes)
-
- Jan 17, 2020
-
-
Georges Racinet authored
clearly a leftover of past hesitations about the variable
-
- Jan 16, 2020
-
-
Georges Racinet authored
What this really does is make `ui.system()` pass the `HEPTAPOD_*` environment variables to the resulting subprocess. Since `ui.environ` is used as a WSGI request-local substitute to the (process-wide) environ, the question whether it should be always fully forwarded will have to be raised in Mercurial upstream. In the meanwhile, Heptapod will pass its variables to external hooks. Closes: heptapod#72
-
- Jan 19, 2020
-
-
Georges Racinet authored
-
- Jan 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
From now on, we should upload this to PyPI, although it's still pretty useless without our *fork* of hg-git (that we can't have there).
-
- Jan 15, 2020
-
-
Georges Racinet authored
Because they are never called for other Git operations than receiving pushes, they are not expected to be triggered by local merges or imports.
-
Georges Racinet authored
-
Georges Racinet authored
I don't want to repeat all the flags here, it does not test anything behavioural.
-
- Jan 14, 2020
-
-
Georges Racinet authored
Rather than listing all these flags painfully on the command line of wherever imports are called from the Rails application, this simple setting will rule them all
-