- Oct 28, 2021
-
-
Georges Racinet authored
This solves this problem in tests of testhelpers: # actual error is FilteredRepoLookupError up to 5.9 and will # be InputError in 6.0 (current default head of Mercurial, does not # bear the version yet) > with pytest.raises(error.Hint) as exc_info: E TypeError: expected exception must be a BaseException type, not Hint heptapod/testhelpers/tests/test_repo_wrapper.py:54: TypeError The queston would be whether it'd be reasonable to make `error.Hint` subclass `Exception` (or `BaseException`). Also pytest<6 works for me, but that doesn't mean pytest 6.0.0 was the one to start demanding exceptions to be subclass `BaseException`.
-
- Oct 25, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Here we consider straight Abort errors to be user errors, hence not warranting a server-side traceback in the logs. This can certainly be improved further, as it doesn't prevent server-side tracebacks to be displayed to SSH clients, for instance. This makes use of `hg-loggingmod` 0.3.0 ability to log tracebacks in the logs.
-
- Oct 17, 2021
-
-
Georges Racinet authored
This is not upstream in mercurial_testhelpers because it depends on the `prune` command.
-
Georges Racinet authored
This long-running named branch was to carry intrusive changes necessary for operation without any auxiliary Git repository. As of !65, we've reached the point were everything is neatly separated and fully optional, depending on choices made by the other Heptapod components. I have checked as thoroughly as possible that using the `hgitaly2` branch of py-heptapod didn't break anything (unit/integration tests, functional tests).
-
Georges Racinet authored
This is to make sure everything is alright before we merge the hgitaly2 branch into default. (to be ignored in the final merge)
-
- Oct 12, 2021
-
-
Georges Racinet authored
This allows the Rails application to switch to the mode without any conversion to Git.
-
Georges Racinet authored
This introduces the new `NoGitStateMaintainer` class, whose usage is triggered by the new `heptapod.no-git` boolean parameter, which is false by default. The new `no_git.test_integration` test module is an adapted copy of `git.test_integration`, written in such a way that `diff -u` between the two source files is readable, to help with maintainability. This may result in some weird line breakings and the like.
-
- Oct 17, 2021
-
-
Georges Racinet authored
These should be only spelling and type changes, meant so that the diff with the future tests of a native state maintainer without a Git repository are easier to compare with these. This explains some weird line breaks, such as: ``` wrapper.commit_file( 'foo', message='some msg') ``` because it will become in the tests for the future class something like ``` ctx = wrapper.commit_file( ``` with the second line unchanged. We also take the opportunity to modernize the calls to the deprecated `write_commit()`.
-
Georges Racinet authored
Because of a missing `parent` keyword in `write_commit()`, the rebase was actually trivial. The factorization with `test_topic_add_rebase_publish()` will make it easier to adapt for the future state maintainer with no Git repo.
-
Georges Racinet authored
The back conversion was converting the 2-tuple to a list of length 2. This didn't change anything in the end serialization (`json` converts tuples and lists alike anyway), but it was a small pain for the writing of uniform test cases for future native state maintainers without any back-conversion.
-
Georges Racinet authored
This makes `git.test_integration` more readable and will be used identically in tests for the future state maintainer with no Git repository.
-
- Oct 11, 2021
-
-
Georges Racinet authored
In the fully native mode, without any conversion to Git, it will still be potentially useful to be able to read a leftover Git repo if the GitLab project was marked as fully native without the expected call to the various `ensure_*` methods. But we don't want any Git repo to be created, and that is a side effect of using `self.git.refs`. In Heptapod functional tests, we will add assertions on absence of Git repo to be 100% sure that they pass without any unwarranted help (one could imagine first an empty repo, then a push would trigger the mirror and suddenly one is not testing the fully native mode as expected). It would be tempting to init the default GitLab branch directly as `branch/default`, but that would be the implicit false promise that there is a commit on the `default` branch, and our logic to correct the initial default Gitlab branch name is probably not able to cope with that. So better keep the default Git value.
-
Georges Racinet authored
It will be useful to test the future `NativeStateMaintainer` class
-
Georges Racinet authored
Some methods of this class will soon not be used by py-heptapod's integration tests. Since they can be useful downstream in HGitaly, we need to keep them and cover them directly.
-
- Oct 13, 2021
-
-
Georges Racinet authored
At least on Python3.7, coverage 6.0 (and/or pytest-cov 3.0.0) break the build with `ModuleNotFoundError: No module named 'hgext3rd.heptapod'`
-
- Oct 11, 2021
-
-
Georges Racinet authored
With the progress made in other components since the creation of the hgitaly2 branch, we will now proceed to introduce a NativeStateMaintainer class that won't do any Git conversion.
-
- Aug 03, 2021
-
-
Georges Racinet authored
-
- Jul 05, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
This is the Mercurial side of heptapod#510 Without this, only the last push option is actually taken into account. See heptapod#509 for the change we'll need to perform in the longer term.
-
Georges Racinet authored
Was obviously a leftover from a local debug session, but is actually really useful, so let's keep it (not at INFO level though)
-
Georges Racinet authored
of course, with a different initial version.
-
Georges Racinet authored
The only immediate application is to test PEP440 compliance, but the motivation was rather that it's now very easily done.
-
Georges Racinet authored
Granted, it's been completely trivial so far, will be a bit less in a minute.
-
Georges Racinet authored
This is the same as what's been done a while ago in hgitaly@27f3a6ac3278. Benefits: - uniformity in release procedure with HGitaly - easier to script (actually also easier to hand edit)
-
- Jul 01, 2021
-
-
Georges Racinet authored
That is why it's not so good an idea to make a topic for release matters (forgot to update after pull). In that precise case, it's not worth a new version
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Because the post-receive hook is now called in the locks release callback, we need to make sure it doesn't use anything that the release just invalidated, notably weak refs. But the hooks were only using the repository object for - the path to the repository (taking sharing into account) - `repo.ui` We now extract these two elements, and immediately delete the reference to the repository object. Both linters and the tests with full coverage complete the proof that no other use is occurring.
-
Georges Racinet authored
This is a merge of change done on the stable branch, where it was restricted to Merge Request creations by pushvars to limit the risks. In all cases, it makes sense to send the post-receive only after new writes are permitted, because there's no telling what writes the Rails app would need to perform directly. As far as I understand, Git locking is weaker than Mercurial's, as it happens on a file-per-file basis. That's why the Rails app could easily grow new problematic writes that wouldn't be rejected by locks in the Git case.
-