- 02 Nov, 2020 1 commit
-
-
Sushil Khanchi authored
This method will help us to easily run any hg command; and it will automatically prepare the env and other such thigns. --HG-- branch : heptapod
-
- 25 Nov, 2020 2 commits
-
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
Georges Racinet authored
The callers actually expect this Gitaly Response object to be returned straight to them. Being a pure data object, that doesn't come as a shock. --HG-- branch : heptapod
-
- 18 Nov, 2020 2 commits
-
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
Georges Racinet authored
As explained in the comment, we can have some conversion attempts while the repo is empty and has no map file. Specifically, this fixes fil creation from the Rails app on empty repositories. --HG-- branch : heptapod
-
- 17 Nov, 2020 2 commits
-
-
Georges Racinet authored
This last direct use of `hg_sha_map` obviously can't do the right thing on HgitalyRepository, where the Hg SHA is just "the" SHA. --HG-- branch : heptapod
-
Georges Racinet authored
The less underlined in Emacs, the best it will be. --HG-- branch : heptapod
-
- 16 Nov, 2020 1 commit
-
-
Georges Racinet authored
Closes #368 To let merges done from the Rails application be checked against the distinct set of merge rules rather that push rules, GitLab looks for MRs matching the pre-receive changes by comparing with the merge commit sha that's always available (and set by the Repository Model) before the actual branch move. Because the Mercurial change can be atomic, we have no other option than passing a special parameter down from `Repository#merge` through the Mercurial backend, with the `HEPTAPOD_ACCEPT_MERGE_ID` environment variable. In turn the Mercurial process will add it to its pre-receive hook payload, and the target branch can be compared to switch from (direct) push to (Rails) merge mode. In the case of merges intended from the very beginning to be fast forwards, the commit sha is already known in advance, but we're using the same mechanism for consistency in the check. Finally, there was a good dose of wrestling with those RSpec examples that care about merging to a protected branch, because of the on-demand nature of instantiation. --HG-- branch : heptapod-stable
-
- 15 Nov, 2020 1 commit
-
-
Georges Racinet authored
Of course the value is `no` for `HgGitRepository` and `yes` for `HgitalyRepository` Closes #364 and leaving us with lots of small fixes to make it work, as the functional tests already told us. --HG-- branch : heptapod
-
- 07 Nov, 2020 1 commit
-
-
Georges Racinet authored
This is more complicated than what we've done earlier for `RefService`: - Upstream passes down storage to `GitalyClient.call` as `@repository.storage`. We don't want to change all methods of CommitService because it wouldn't apply readily to new methods from upstream. Hence we actually re-instantiate `@repository`, with the VCS-qualified storage, with the new `vcs_storage_clone` method. On the side, this also requires a small change in HgGitRepository to make the value admissible. - only a subset of Commit service methods are actually involved in our first round of HGitaly implementation (getting rid of Git SHAs, see HGitaly1 milestone). We're deciding here that the other methods will use directly the original storage name, that we store as a new instance variable, `@git_storage`. In particular, we're trying to avoid the implementation of the various methods for Commit content (files, trees, diffs…) for the HGitaly1 milestone. This part is WIP (we'll need to convert back to Git revisions to complete it). - Finally, this hack also requires to make sure that the resulting Commit instances refer to the original Repository, so that further (H)Gitaly calls done from these Commits don't reuse a VCS-qualified storage, which would defeat the very purpose of separation. This is all very hacky. The only thing that makes it admissible is that it is temporary scaffolding. For the HGitaly2 milestone, all methods will go to HGitaly, and perhaps we can convince upstream to use a `@storage` instance variable here for the sake of uniformity. --HG-- branch : heptapod
-
- 25 Oct, 2020 2 commits
-
-
In some cases it makes sense to display a different commit ID than the one used for addressing. Of course our existing `HgGitRepository` is a prime example of that, but it's not hard to imagine other ones. Up to now, we've changed some templates and user-facing to code to use directly some 'hgid'. For dual VCS support, as well as intermediate steps towards Mercurial native support, we'll need something more abstract than that. The method name, `hpd_display_id`, is voluntary obnoxious: we want to recognize at first glance that it's Heptapod-specific, and we want it to be easy to find all occurrences in the code base, in preparation for potential future times when we won't be needing it any more. --HG-- branch : heptapod
-
We're also using the `override` helper, which makes sure that there is a method with the same name to be overridden, hence providing protection in the case of renames in the base class. We don't provide tests in the HGitalyRepository case in this commit: this will be the point of the next one. --HG-- branch : heptapod
-
- 19 Oct, 2020 9 commits
-
-
Georges Racinet authored
Closes #359 --HG-- branch : heptapod
-
Georges Racinet authored
This is essentially promoting `HgGitRepository#hg_branchmap_branch`, as the proper base for `Mercurial.branchmap_key_for_gitlab_branch`. It can also turn out to be useful elsewhere. --HG-- branch : heptapod
-
Georges Racinet authored
--HG-- branch : heptapod
-
Georges Racinet authored
At the time passing project id was introduced, it was convenient to support both Heptapod 0.12 and 0.13. In these Heptapod ≥ 0.16 times, it's quite useless. --HG-- branch : heptapod
-
Georges Racinet authored
This just reuses the previously introduced flag with the same name in `hg_env_for_write` --HG-- branch : heptapod
-
Georges Racinet authored
This will simplify the work of callers that need to run with full administrative permissions and may not have an obvious user to choose from (imports, mirroring pulls…): hg_env_for_write(nil, force_system_user: true) We now explicitely forbid the case where user is `nil`, except when `force_system_user` is `true`. --HG-- branch : heptapod
-
Georges Racinet authored
This is for now a corner case, but we'll treat it in a more appropriate manner right afterwards. --HG-- branch : heptapod
-
Georges Racinet authored
--HG-- branch : heptapod
-
Georges Racinet authored
With two typos, it was really quite obscure --HG-- branch : heptapod
-
- 18 Oct, 2020 1 commit
-
-
Georges Racinet authored
This will be an interesting low-level helper, being exposed on the `Repository` model automatically, like all "raw" repository methods. Like all write methods, a valid `user` argument must be passed. --HG-- branch : heptapod
-
- 14 Oct, 2020 1 commit
-
-
Georges Racinet authored
For archive production, the Rails app duty is to return direct connection information to Workhorse, so that it can call Gitaly directly. We're reusing the dispatching logic for our existing (yet unplugged) HGitaly integration: by prefixing the storage (shard) with `hg:` for Mercurial repositories, we have the `GitalyClient.address` return connection information for the HGitaly server. For this to work, we need `archive_metadata` method of the Mercurial Repository classes to provide the Mercurial SHA, which we do by intoducing the dedicated `archive_sha` method. --HG-- branch : heptapod
-
- 09 Oct, 2020 1 commit
-
-
Georges Racinet authored
This is for now mostly intended as a helper for tests. We're using one of the HGitaly tags test to make sure it works, and in turn that test gets simplified. There's a catch: `hg_git_repository.hg_tag` would not work before `subject` has been used at least once, so that the repository is indeed initialized on disk. If we were in need to use `hg_git_repository` here, we'd have to switch to `subject!` instead of just `subject`. --HG-- branch : heptapod
-
- 24 Sep, 2020 2 commits
-
-
Georges Racinet authored
Spotted by the rate limit on Gitaly calls. We're simply caching the result if it's positive. --HG-- branch : heptapod-stable
-
Georges Racinet authored
Too bad if I personally consider it better style to make that we're return nil explicit in case of methods actually expected to return something (clear intent, and nicer to people not used to the language). --HG-- branch : heptapod-stable
-
- 10 Sep, 2020 1 commit
-
-
Georges Racinet authored
The `CommitReferenceFilter` class is the one responsible for the rendering. We're *adding* resolution of truncated Mercurial Node ids for the case of the `hg_git` VCS type, relying on the existing map of full Mercurial SHA (Node id) to Git SHA. This is very inefficient, and proper calls with low startup overhead to a persistent Mercurial nodemap would do much better above a certain repository size (persistent nodemap is provided by Rust native extensions, and low overhead would be achieved only by a fastpath without Python or a long-running process, such as HGitaly) While the `Git::Commit.batch_by_oid` method doesn't seem to be called except from the `#commits_by` method of the `Repository` model, the latter is used in several places of the application, with risks of breakage and/or severe performance degradation. For `hg_git` VCS type, most callers don't need the Mercurial resolution. That's why we're executing the new lookup only if the new `hg_full_resolution` argument is set to `true`. Preliminary performance analysis (non scientific, on my workstation) shows that in the 100k changesets range (pypy repo) this naive lookup takes about 30ms, whereas `hg log -T` is in the 100-200ms ballpark. Around 500k changesets (mozilla-central repo), times have the same order of magnitude (around 100-200ms again). To insist, this is with the hg startup overhead and without the Rust persistent nodemap (would take less than 1ms). We fully expect the current hg<->git maps to be an unbereable performance problem in Heptapod anyway around 500k to 1M changesets anyway, only solved by HGitaly. All in all, the performance question seems to be acceptable in the current inefficient context *for Note rendering*. HGitaly would provide an efficient RPC call anyway. --HG-- branch : heptapod-stable
-
- 27 Aug, 2020 3 commits
-
-
Georges Racinet authored
Closes #334 Normally, the abstraction layers in GitLab mean that the Project should not be accessible from the low level repository. However, we need it to pass it down to the `hg` processes. Doing it in `hg_env_for_write` is the way to make it really robust, since all write operations basically have to use it. To mitigate somewhat this breach of abstraction, we make the attribute writable only, and we give it a more specific name than just '@project'. Aesthetically, it would be better to store only a factory for the `UserAccess` instance that we really need, but that could be done separately. This required running some of `HgAccess` RSpec tests with empty repositories, because in them, the project owner does not have enough rights to create a first commit any more, and there's not even an admin user around for that. --HG-- branch : heptapod
-
Georges Racinet authored
We still have a deprecated compatibility alias, and the rebase tests prove that it works. --HG-- branch : heptapod
-
This new attribute is not meant to be used in any other context than RSpec tests, whence the name. It allows us to use higher level methods such as `multi_action` in tests setups and will be necessary to test them. Upstream does something similar with no need to involve the tested code: they launch Gitaly server with the `GITALY_TESTING_NO_GIT_HOOKS` environment variable. --HG-- branch : heptapod
-
- 26 Aug, 2020 2 commits
-
-
The main point is to make it easier for developers to tell apart the case of status code 1. Note that output is usually empty, being redirected to the logs. --HG-- branch : heptapod
-
--HG-- branch : heptapod
-
- 24 Aug, 2020 2 commits
-
-
Georges Racinet authored
This is a variant of #332 for multi_action. As with the case of merge requests, the check should also be performed at low level by Mercurial, but doing it at the model level makes for early failure, avoiding atomicity issues. A difference with MRs is that we don't have a simple way *not* to propose the action to the user yet, because higher layers are more complicated and don't involve checks, since they are meant to produce forks for users without write permission. This currently provides 500 errors, but at least it closes the security problem, and we can later on add the necessary catching. We didn't want to affect Wikis, because for them, allowing publication for Developers is pretty normal. --HG-- branch : heptapod-stable
-
Georges Racinet authored
This is just cleaner and prone to reuse. --HG-- branch : heptapod-stable
-
- 03 Aug, 2020 1 commit
-
-
Georges Racinet authored
Closes #324 The specific repo configuration was ignored in all Mercurial operations initiated by the Rails app. I've considered making links instead of copying the file, but it could give rise to funny situations if the original HGRC files get changed in concurrency with some operation. Edition of the HGRC files is by no means atomic in itself, but that's a separate issue. On the other hand, operations can be arbitrary long, involving several calls to the `hg` executable. One would not want the rules to change in the middle of that. --HG-- branch : heptapod
-
- 17 Jul, 2020 1 commit
-
-
Georges Racinet authored
It's cheap and it can unblock a repo. --HG-- branch : heptapod-stable
-
- 16 Jul, 2020 4 commits
-
-
Georges Racinet authored
This will be useful for an incremental approach of configuration setting, and spares us INI format parsing in Ruby (GitLab does not come with a gem for this). --HG-- branch : heptapod-stable
-
Georges Racinet authored
Because `hg config SECTION` exits with code 1 if no matching setting have been found, we previously had an error if this method (and the corresponding API endpoint) was called before any local setting is set in the `[heptapod]` section. This can be considered part of #299, too Also fixed the exception raising, Ruby has its quirks, not the same as Python's. --HG-- branch : heptapod-stable
-
Georges Racinet authored
Closes #299 We'll return content to be `nil` in that case, which will be conveyed as `null` in the JSON API. --HG-- branch : heptapod-stable
-
Georges Racinet authored
Closes #314 Previously only the Git repository was considered. Note that this is cached in the `projects_statistics` table, and can be invalidated by doing ``` project.statistics.refresh! ``` This seems in turn to be triggered by `UpdateProjectStatisticsWorker`, iself called by `ProjectCacheWorker`, from the likes of `PostReceiveWorker` etc. --HG-- branch : heptapod-stable
-