- Feb 28, 2024
-
-
Georges Racinet authored
Nothing serious, no change to main code. All explanations in comments.
-
- Jan 15, 2024
-
-
Georges Racinet authored
Closes #169
-
Georges Racinet authored
Nice demonstration that fields are typed, but objects not so much.
-
- Nov 20, 2023
-
-
Georges Racinet authored
It was a mistake to depend on `load_repo`, as it will fail if, e.g., the `.hg` sub directory does not exist (seen in Rails RSpec tests) and various corrupted cases that a *removal* should clean up. The price to pay is the transactionality of the roster, but we cannot lock it properly without a repo. In theory in should be possible to instantiate the `Vfs` separately, but it does not seem to matter so much. With this change, if removing the working directories fails, it will not prevent removing the trashed repository (but of course we risk a later collision in workdirs). Backs out in particular changeset 1c735d40cfe7
-
- Nov 18, 2023
-
-
Georges Racinet authored
Now that we need to load the repo for the working directories machinery, no need to repeat the exceptions that can be raised by the loading. The only difference lies in the error message on missing repository, which we are confortable ignoring.
-
- Nov 12, 2023
-
-
Georges Racinet authored
We chose to use the same detector as Gitaly's: go-enry/go-license-detector, so that we get the same results. Of course this means we have to provide it in CI and Omnibus builds. Closes #161
-
- Nov 10, 2023
-
-
Georges Racinet authored
In the case of unknown storage, we find it useful to repeat the requested name, hence we simply stop comparing exactly the details. In the case of the missing repository field, the new upstream message is clearly better, so we adopt it.
-
- Sep 19, 2023
-
-
Georges Racinet authored
This iterator-based approach just keeps a small window of up to 3 lines in RAM, instead of the full list previously obtained with splitlines()`). It uses `collections.deque` (natively implemented), to make sure the window will never be reallocated. On the other hand, matching lines are allocated afresh, which is expected not to be a problem. At this point, further improvements should take the form of an implementation in RHGitaly.
-
- Sep 17, 2023
-
-
Georges Racinet authored
First working version that should make CI happy, can be improved (CPU and RAM efficiency).
-
- Aug 07, 2023
-
-
Georges Racinet authored
Adaptation to match changes of Gitaly error details in `CommitService.TreeEntry`
-
- Jul 31, 2023
-
-
Georges Racinet authored
This method is mostly used to check if the repository is emtpy (and that is in the case of Mercurial logically equivalent), but it's better to implement it using the GitLab branches file as it avoids actually opening the repository, spawning a thread for blocking iteration etc.
-
- Jul 11, 2023
-
-
Georges Racinet authored
Actually, this method is called by `gitaly-backup` as of Gitaly 15.10 only (forwarded to the Rake task in upstream Git commit 4be1f22815bed, part of the 15.11 development cycle, not imported in Heptapod Rails repo yet). Also, since for the time being an HGitaly storage always comes on top of a regular Gitaly storage at the same path, we will actually want *not* to call the HGitaly version for lots of time.
-
- Mar 19, 2023
-
-
Georges Racinet authored
We chose to compare RHGitaly with Gitaly rather than with HGitaly because it's not impossible that we stop at some point maintaining some methods in the Python code (time will tell). It is likely that we'll end up implementing some of the HGitaly-specific methods in RHGitaly (e.g. reading phases, topics and whatnot). In that case we'll need comparison between HGitaly and RHGitaly, but that will be some much simpler (no correspondence of Git content) that we will provide it directly. This fully hooked in CI/CD. We had to anyway: otherwise the new test would not pass. Implementation details ---------------------- We add the capability to start RHGitaly, with a simple `cargo run`. This is validated independently by `test_rhgitaly_server` (homologous to `test_gitaly_server`). The `GitalyComparison` class (of which the `gitaly_comparison` fixture is an instance) now gains an optional `rhgitaly_channel`, which is set and exposed in the new `gitaly_rhgitaly_comparison` fixture. Finally, using `rhgitaly_channel` rather than `hgitaly_channel` is left to the `RPCHelper` class, with its `hg_server` argument. Since it is instantiated from inside the tests, it is easy to pass `hg_server` down from a parametrization, reaching the end goal: the very same test is run for HGitaly and RHGitaly, compared in both cases with Gitaly. This is illustrated in the test for `RepositoryExists`. Two annoyances had to be taken care of: - we need to ignore the `rust/` directory in `run-all-tests` because it makes pytest collection crazy (hangs forever) due at least in part to Mercurial full source being present by default in `rust/dependencies` - Tonic seems to add trailing metadata that Gitaly does not. We had to remove them in `assert_compare_errors()`. CI/CD assumptions ----------------- The base image `heptapod-gitaly` is now expected to provide - the Rust toolchain - a clone of Mercurial sources. It can be daily or weekly, we make a share and update it - `rust-protobuf`: could be trimmed, as we only need the protocol files and don't need to update them for each build
-
- Apr 12, 2023
-
-
Georges Racinet authored
Part of #80. As noticed by the functional tests at heptapod-tests, this is mandatory for Wikis using regular gRPC calls, which are rolled out in GitLab 15.5
-
- Mar 22, 2023
-
-
Georges Racinet authored
As it was uncovered by experimental implementation in RHGitaly of `RepositoryExists`, it's possible that the `repository` argument is entirely missing. In that case, we are now raising `ValueError` internally, and convert it to the gRPC code `HGitalyServicer.STATUS_CODE_STORAGE_NOT_FOUND`.
-
Georges Racinet authored
Up to know, we were thinking that raising `KeyError` and setting code and details on the context was enough, but apparently, it is at least problematic with streaming gRPC methods. We're instead using the two-layer organisation that was suggested as comment in `service.repository`. As it turns out, the error code to set in case of unknown storage depends at least on the service. This was already visible in the error treatment of the full path methods of `RepositoryService`, which does not need to be specific any more. The new `STATUS_CODE_*`class attributes make it easy to tweak the error code in service implementations. Specific methods could override them with instance attributes if needed. In the process, we're basically giving up on providing the same `details` as Gitaly: these are highly dependent on implementation (it's just stderr if the implementation relies on a `git` subprocess) and chances that it may matter are low, given that GitLab these days pushes towards "structured errors", i.e. with programmatically usable details provided in metadata. As a result, the normalization of error details in `assert_compare_errors` is not used any more. We're keeping it in the code base, as it may turn useful for forthcoming tests were the details would not be a simple stderr echo.
-
- Dec 13, 2022
-
-
Georges Racinet authored
Less boilerplate with `RpcHelper`, now that it can normalize error details.
-
Georges Racinet authored
Closes #114
-
- Oct 25, 2022
-
-
Georges Racinet authored
See #111, this is shortly after v15.1.0-rc1, but not an ancestor of v15.1.0. Brings in in particular: - rename of `repository-service.proto` to `repository`.proto, without changing the contents, though - usage of `errors.proto` There is a change of wording in the error details for FindChangedPaths that we have to follow in Comparison Tests, and don't need to check in such detail in ordinary integration tests.
-
- May 10, 2022
-
-
Georges Racinet authored
In case of error after repository creation, Gitaly makes sure to remove the created repo. We must do the same, and it opens up room for retries.
-
Georges Racinet authored
-
- Apr 28, 2022
-
-
Georges Racinet authored
Closes #95 This is in advance of the HGitaly3 milestone, but needed for gitaly-backup (removal occurs before restoration). We don't attempt to provide the same level of locking as Gitaly does, both because this is not the best time to handle locking for mutation methods and because this is a special case, but we split the work into atomic rename and cleanup (cheap to implement). See also heptapod#534
-
- Oct 09, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
This func will be used by upcoming tests of CreateRepositoryFromRefList().
-
- Aug 28, 2021
-
-
Sushil Khanchi authored
-
- Mar 29, 2022
-
-
Sushil Khanchi authored
Rebased and amended by gracinet
-
- Feb 15, 2022
-
-
Georges Racinet authored
In version 14.6, Gitaly makes it an error to attempt to create a repository if anything already exists at the target path (even broken symlinks). This is worth a minor version change. This deprives us of the way we were triggering actual repository creation errors in tests. To maintain coverage, we're now using the broken symlink trick one step higher in the file hierarchy: on the storage itself. Playing with permissions would not work in CI.
-
- Oct 20, 2021
-
-
Georges Racinet authored
Perhaps at some point Gitaly will decide that the proper error code should be `NotFound` or to stop providing the full path in the details, but we are meanhile doing the same. The only difference in error treatment is the replacement of 'git repository` by 'Mercurial repository' but as usual I'm betting on it not to matter.
-
- May 31, 2021
-
-
Sushil Khanchi authored
-
- Mar 25, 2021
-
-
Sushil Khanchi authored
-