- Jun 11, 2023
-
-
Georges Racinet authored
The changes don't affect the small subset of methods that we implement.
-
Georges Racinet authored
-
- May 31, 2023
-
-
Georges Racinet authored
The only change in protocol is the addition of `DiffService.GetPatchID`, see #131, that does not seem to be used yet in the Rails app. The only adaptation needed for Gitaly Comparison tests to pass against v15.8.0 is the error details in `CommitService.TreeEntry`
-
- May 30, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- May 28, 2023
-
-
Georges Racinet authored
There are many special cases, the nicest being that `HEAD` is not emitted if nothing else matches (probably not intentional, hence not being relied upon, but one never knows). Closes #130
-
- May 26, 2023
-
-
Georges Racinet authored
This is the bare minimum so that the Rails app can work. Part of #130
-
Georges Racinet authored
Decreasing redundancy
-
- May 24, 2023
-
-
Georges Racinet authored
Bumping the protocol, and fixing the problems spotted by Gitaly Comparison tests. Many methods in `RefService` are being deprecated in favor of the `patterns` and `sort_by` options in `ListRefs` that are not implemented in HGitaly (see https://gitlab.com/gitlab-org/gitaly/-/issues/3966). Therefore implementing them is mandatory to claim compatibility. ## Fixed Comparison tests The discrepancies were due to - upstream keeps on removing the inappropriate `UNKNOWN` error codes in favor of `INTERNAL` - upstream keeps on removing the name of the Golang function that emitted the error in the details (it is usually either an irrelevant implementation detail or just redundant with the gRPC method name)
-
Georges Racinet authored
Done before the bump of Gitaly reference version to 15.7 to have Gitaly comparison test for `FindCommit`
-
Georges Racinet authored
Now proceeding to match Gitaly v15.7
-
Georges Racinet authored
-
Georges Racinet authored
The bump to Gitaly protocol 15.6 is enough for a minor version change, and we need a landmark if we need to release Heptapod 0.37.6 (GitLab 15.6) in some future.
-
- May 12, 2023
-
-
Georges Racinet authored
For instance, in the case of pipelines for the py-heptapod default branch, a HGitaly pipeline is triggered, but it fails and the upstream pipeline fails.
-
- May 16, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
A bit nicer in `test_ref` and will also be needed in `test_commit`
-
Georges Racinet authored
This already reduces duplication in `test_ref`, and will be reusable by other test modules.
-
Georges Racinet authored
The previous way of invalidating the Mercurial to Git map was to delete the cached property, but it raises an error if it has not been used before. In theory the invalidation could be removed if not necessary any more. In practice, this forces to check that it is normal. Better to encapsulate. Also, for simplicity, we also invalidate Mercurial caches by reloading the repo.
-
- May 15, 2023
-
-
Georges Racinet authored
There was even an old TODO about that
-
Georges Racinet authored
This method of the `CommitService` had no Gitaly Comparison test, because it was implemented before these tests were even considered. Such a test will be the main testing of the upcoming RHGitaly implementation. It turns out that we found a missing case: tag in the fully qualified ref notation (chances are that clients woud rather use `RefService.FindTag` but one never knows.
-
Georges Racinet authored
In some cases where a message attribute is missing, our normalization would have replaced it with a default (empty) value, leading to false positives. This is for instance the case of an empty `FindCommitResponse` (no commit attribute) that it would convert to a `FindCommitResponse` with an empy `commit` attribute (part of actual tests in the process of being written).
-
Georges Racinet authored
A separate method for each "attribute path" gives us a bit more clarity (early return if `recurse` rather than a boolean available from outside the inner loop), and more room for improvement.
-
- May 12, 2023
-
-
Georges Racinet authored
## Protocol The protocol is the same in all Gitaly v15.6 versions, including the one used in GitLab v15.6.0-rc42. The protocol changes from 15.5 have no impact on HGitaly. ## Visible method changes The removal of the feature flag for `FindLocalBranches` has already been treated in the parent changeset. The only remaining change we have to match Gitaly 15.6 is very minor (error details wording). ## Feature flags change Two changes got our attention: - [convert_err_to_status](https://gitlab.com/gitlab-org/gitaly/-/issues/4587): is actually about internal implementation details on how to generate `INTERNAL` status code with less boilerplate - [tree_entries_new_page_token_format]: changes the token content only because it had collisions, notably in the face of empty blobs (see message of Gitaly commit eb82c328b2a3ca312724724eb9849bc25a3b0b24). Our own token is the blob id, but is based on path instead of content, so this is irrelevant to HGitaly. We'll have not to make the same mistake if some day we implement content-based addressing.
-
- May 14, 2023
-
-
Georges Racinet authored
The `simplify-find-local-branches-response` feature flag gets removed in the upcoming Gitaly 15.6
-
Georges Racinet authored
Done as a merge from stable branch, before the bump to Gitaly 15.6
-
Georges Racinet authored
Recent Gitaly versions come with two versions of Git (probably to test them in advance), and hence the path that we were trying is no longer valid. It is now mandatory of to the development setup (HDK) and to the CI base image to provide Gitaly with the bundled Git. The concept of "bundled Git" seems to go beyond vendoring, the compilation flag `WITH_BUNDLED_GIT=YesPlease` has the effect of putting self-sufficient Git executables in Gitaly bin directory, which the main executable knows how to find and select, provided that the `bin_dir` configuration item is correct (fixed in a preparation changeset). Using this bundled Git removes lots of confusion and timebombs such as the tests defaulting to a system-wide Git which suddenly can become outdated.
-
Georges Racinet authored
Since we only test one candidate `gitaly` executable, we don't need the loop.
-
Georges Racinet authored
In case the `gitaly` executable is to be found in a subdirectory of `GITALY_INSTALL_DIR`, then that same subdirectory has to be provided as the `bin_dir` configuration item, so that Gitaly can find all its non-ruby bundled executables, notably the bundled Git. It was working until now because Gitaly falls back to a system-wide Git if the specified one is not found, whose version is acceptable in CI because the `heptapod-gitaly` base image is itself based on the `heptapod-base` image, which provides the Git version generally accepted by the target GitLab version. Since there is no doubt as to where the `gitaly` executable is supposed to sit, we're only testing one possibility (minimal change to keep the diff understable, to be refactored).
-
- May 03, 2023
-
-
Georges Racinet authored
-
- May 01, 2023
-
-
Georges Racinet authored
Hoping this will reuse intermediate object files from the artifact uploaded by the `tests-rust` job
-
- Apr 30, 2023
-
-
Georges Racinet authored
Again, we don't want the application to be locked for the wrong reason, e.g. lock held by a former process, but hostname has changed in the mean time. We also take the opportunity to use shorter timeout and delay betweeni locking attempts. The customatbility of the breaking logic and of the timeouts could be submitted UPSTREAM as options to Mercurial core, although it would be of limited interest to Heptapod right now: we cannot readily apply the same logic to other Mercurial locks, because HGitaly does not have exclusivity on them. Querying the system service manager (systemd or runit) about the Heptapod services would be a promising idea to do better, but we'd still have the issue that pushes over SSH would create standalone processes.
-
- Apr 26, 2023
-
-
Georges Racinet authored
The rationale is that if a working directory is being held by a process (existing or not) that is not considered part of the HGitaly system service, it means that the process was killed before it could release the working directory and the pid is either not in use or has been reused for an unrelated process. The underlying assumption is that only HGitaly is supposed to make such working directories. This could be further expanded to the roster lock. Had to put `is_current_service_process` in a separate top level module instead of, e.g., `server.mono` to avoid import loop: server.mono imports services import workdir import server.mono We need to use pytest-cov's `cleanup_on_signal` again. This time, it's easier as the subprocess startup function is defined by the test itself.
-
- Apr 25, 2023
-
-
Georges Racinet authored
The trick is that we fall precisely in the case where pytest-cov needs a hand: termination by signal (SIGTERM), hence we need the `cleanup_on_signal` method. Unfortunately, this does not work with pytest-7.3.1 and pytest-cov-4.0.0 as the previously lax `test-requirements.txt` would install (detected on the `heptapod-gitaly` base image, which does not preinstall these), so we fix versions as they are in py-heptapod (hence also as they already were in HDK settups, since `py-heptapod` is installed first). Then, we need the server to actually be running to be sure that the handling has been done before we terminate. Still not covering the case of `SIGINT` while doing some Mercurial processing. We'd probably need to launch a long enough gRPC method for that.
-
Georges Racinet authored
This makes it importable from the whole code base, and is already somewhat cleaner in the `tests_with_gitaly.rhgitaly` module.
-
- Apr 24, 2023
-
-
Georges Racinet authored
This wraps things together by passing down the proper root of working directories for the given repo (as prescribed in the Gitaly `Repository` message. The test is a simplified version of a service method creating changesets.
-
Georges Racinet authored
It has already been the case in Heptapod that relative path in Gitaly Repository messages were to be passed as if the repository was a Git repository (hence ending in `.git`) and then to be normalized as `.hg` for Mercurial operation. But this is due to the legacy hg-git based integration, and could not be necessary in some future. Meanwhile, we'll need to reuse the logic for working directories.
-
Georges Racinet authored
This is to be called as part of ordinary housekeeping. Another subject to be tackled on would be release of working directories held by defunct processes, which would introduce a more satisfactory breaking logic, also applicable to the roster lock.
-
- Apr 09, 2023
-
-
Georges Racinet authored
This creates the pool, recorded as a "roster" file in the main repository. To obtain an exclusive working directory, callers should use the `working_directory` context manager only. The roster file is protected by a lock, with input/output occurring only at acquire and release times of working directories, allowing to acquire working directories freely when one is already held. The lock is for now provided by Mercurial standard utilities, but we will probably implement a more suitable one later on. A cleanup system for old working directories shall be implemented in a following changeset. It will be based on the recorded timestamp.
-
- Apr 28, 2023
-
-
Georges Racinet authored
-