- 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
-
- 01 Dec, 2020 1 commit
-
-
Georges Racinet authored
The previous change was only about the required version (the one recorded in the Rails checkout), and was still reading the upstream version file for the actually running GitLab Shell. Closes #375 --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 1 commit
-
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
- 21 Nov, 2020 1 commit
-
-
Sushil Khanchi authored
--HG-- branch : heptapod
-
- 20 Nov, 2020 1 commit
-
-
Georges Racinet authored
The reason is that the RSpec launch sequence really installs GitLab Workhorse (that does not matter for the time being), using `Gitlab::Workhorse::version`. Of course if that is actually Heptapod Workhorse version we have a problem. In the helper (used only in the admin dashboard), it's taken from headers anyway, but still we provide an appropriate fallback method (grafted from 24ca3aba6354, this was a last-minute fix to let the CI do its job, that was validating the release) The question of really installing Heptapod Workhorse will stay irrelevant for a while: we would need to - launch tests that use Workhorse - that the difference between GitLab and Heptapod Workhorse actually matters. --HG-- branch : heptapod
-
- 18 Nov, 2020 1 commit
-
-
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 1 commit
-
-
Georges Racinet authored
With Mercurial, many non-force pushes look like ones for GitLab because of obsolescence. On the other hand, the Mercurial backend has already applied its relevant protections against that. Also, really important: if this is called ultimately from a pre-receive hooks, the Mercurial transaction is still ongoing. Therefore ancestor? will raise an 'unknown revision' error, breaking everything. --HG-- branch : heptapod
-
- 16 Nov, 2020 1 commit
-
-
Georges Racinet authored
Method provided by a service not plugged in at all, hence provided by back-and-forth conversion to Git. --HG-- branch : heptapod
-
- 17 Nov, 2020 3 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
-
Georges Racinet authored
Some previous changes did that already, but they left `commit_deltas` behind. We're putting the conversion one step lower in the call chain to catch them all. --HG-- branch : heptapod
-
- 16 Nov, 2020 2 commits
-
-
Georges Racinet authored
These were exceptions to the calling style. `find_branch` is the one interesting for our current goal: make the current functional tests pass. To UPSTREAM. --HG-- branch : heptapod
-
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 3 commits
-
-
Georges Racinet authored
As demonstrated by a functional test, Maintainers were still able to remove the protected branch even if push level was set to `NO_ONE`. The reason is the underlying 'web' protocol. The fix is harsh, but removal is a special case and the explicit message to unprotect the branch should be acceptable. --HG-- branch : heptapod-stable
-
Georges Racinet authored
The fix is simple enough and all functional tests are passing. This is the occasion to restore/adapt the RSpec tests for branch protections. This still have the unwanted consequence that some MR merges will fail, because the related permission checks (occurring in pre-receive API endpoint) won't find the matching MR. This will be handled in a subsequent changeset, for more on this, see #368. --HG-- branch : heptapod-stable
-
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
-
- 14 Nov, 2020 2 commits
-
-
Georges Racinet authored
This is part of #364 and will allow Heptapod Workhorse to set the proper HTTP header to make its hgBackend send the appropriate notifications (Hg SHAs) in this case) --HG-- branch : heptapod
-
Georges Racinet authored
As of this writing, Mercurial native projects still have an auxiliary Git repo. But this was wet blanket bypassing also proper HGitaly calls. --HG-- branch : heptapod
-
- 09 Nov, 2020 4 commits
-
-
Georges Racinet authored
Although they go trough `gitaly_commit_client` they actually call the `DiffService`, not currently implemented by HGitaly at all (obscure generic NoMethod gRPC error, hard to track which caller it was). We need to - use @git_storage to call the regular Gitaly - convert SHAs to Git SHAs This gives us our first working Commit page in the Web UI, but only for Commits without parents. In the (frequent, yes) general case, we still need at least BatchByOids to display the Commit parents list (must go partly through Markdown rendering). This last part will be done after 0.17.0rc1 --HG-- branch : heptapod
-
Georges Racinet authored
This is so often needed that a separate method makes sense. Done at generic level for widest compat (only `HGitalyRepository` can return `nil` by the way). --HG-- branch : heptapod
-
Georges Racinet authored
The `#cached_exists` method can issue a Gitaly call. Of course if it's running for a temporary vcs-cloned as `GitalyCommitClient` uses, that makes for double VCS prefixing and it fails. We correct this, and hence its various conversion callers by subclassing and doing the right thing explicitely. --HG-- branch : heptapod
-
Georges Racinet authored
That wasn't obvious from the naming, but basic actual browsing in the UI failed because these could be just 'branch/default' --HG-- branch : heptapod
-
- 08 Nov, 2020 4 commits
-
-
Georges Racinet authored
Arguably, this method has nothing to do with Trees – it uses paths, not actual Git Tree objects and could therefore be implemented directly in HGitaly. To be frank, if we had come to that conclusion earlier we probably would have made it that way, but now that this code is there, we can as well turn to other pressing matters. A consequence is the `hpd_back_convert!` method, but it could turn out to be useful for something else. Of course, like its cousins in the `Tree` and `Blob` class, we'd prefer not to need it at all. --HG-- branch : heptapod
-
Georges Racinet authored
Similar to what's been done previously for Blob, we switch back to Git mode and the point is the the Tree OID is the Git one, while the corresponding Commit ID is the Mercurial one. --HG-- branch : heptapod
-
Georges Racinet authored
Git blobs are typically addressed by their OID, meaning that we only have to address the few methods that allow to find that OID from a Commit and a relative path. For example, `Gitlab::Workhorse` returns a special payload including the blob OID to the Workhorse server in front of the Rails app, allowing it to serve the full blob content directly from Gitaly. We are systematically calling `gitsha_from_sha` and its converse here, hoping it won't be too much of an overhead. The changes to the `Blob` method are tested through methods of `Repository` (inherited by `HgitalyRepository`) that in turn call them. Comparison with the case of `HgGitRepository` is provided for reference. --HG-- branch : heptapod
-
Georges Racinet authored
For the integration of native Mercurial repositories to reach milestone HGitaly1 (mixed mode still relying on Git conversion for some data access), we will need to be able to convert internally to Git SHAs. Of course, this conversion is trivial for `Git::Repository` and `Mercurial::HgGitRepository`. Various classes in the `Gitlab::Git` module will make use of these methods, `Blob` and `Tree` being the first to come to mind. --HG-- branch : heptapod
-
- 07 Nov, 2020 2 commits
-
-
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
-
Georges Racinet authored
--HG-- branch : heptapod
-
- 01 Nov, 2020 1 commit
-
-
Georges Racinet authored
While the Shell version is directly taken from the VERSION file (now HEPTAPOD_SHELL_VERSION), the Workhorse version is by default taken from the HTTP header that Workhorse adds, ultimately set at build time from the latest tag, with additional information if built on a changeset with no tag. We only change the way the header is parsed, to take into account the additional `heptapod-` prefix it has. --HG-- branch : heptapod
-
- 30 Oct, 2020 1 commit
-
-
Note that hgsha_from_sha is not entirely redundant with commit_id_to_display_id, because it does promise that the returned value is a Mercurial Node ID. --HG-- branch : heptapod
-
- 29 Oct, 2020 1 commit
-
-
--HG-- branch : heptapod
-
- 28 Oct, 2020 1 commit
-
-
This is the index of the last character, hence 11, to avoid a useless -1 in Ruby slicing --HG-- branch : heptapod
-
- 25 Oct, 2020 3 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
-
The position of the overriding method was just wrong. This went unnoticed because the Mercurial archive feature is for now tested with HgGitRepository only. --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 3 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
-