- 27 Nov, 2020 1 commit
-
-
Georges Racinet authored
This will make cleaning up much easier and safer --HG-- branch : heptapod
-
- 28 Nov, 2020 3 commits
-
-
Georges Racinet authored
Predated the introduction of `Project#mercurial?`, obviously. --HG-- branch : heptapod
-
Georges Racinet authored
Before the HGitaly2 milestone, the information is weirdly duplicated with Git, so that it doesn't systematically break if missing. But it does frequently and this is obviously needed. We don't need to differentiate between `hg` and `hg_git` repos, here, thanks to the `tar` flag to ignore missing files. --HG-- branch : heptapod
-
Georges Racinet authored
With the generalization of the hashed storage, it's become less immediately visible that the failure is on a Wiki repo, to the point that I didn't notice that there was already a qualifier at the end of the line in restore case. Care is taken so that future merges with upstream can conflict (good) but not introduce new breakage in error treatment (very bad) UPSTREAM --HG-- branch : heptapod
-
- 27 Nov, 2020 3 commits
-
-
Georges Racinet authored
This will be essential for backups to work, and will have to be reverted for the HGitaly2 milestone. --HG-- branch : heptapod
-
Georges Racinet authored
This was suggested in comment and it really makes sense, now. In the case of Wikis, care must be taken that this will be called on the `ProjectWiki` instance. --HG-- branch : heptapod
-
Georges Racinet authored
--HG-- branch : heptapod
-
- 26 Nov, 2020 1 commit
-
-
Georges Racinet authored
- we don't want users to create mirrors that aren't implemented yet - we want the display of existing mirrors created through API to be correct. --HG-- branch : heptapod
-
- 08 Oct, 2020 1 commit
-
-
Raphaël Gomès authored
TODO actually add the mirroring capabilities --HG-- branch : heptapod
-
- 25 Nov, 2020 3 commits
-
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
Raphaël Gomès authored
Part of #306 For general design of the feature, see 952df9a233a9 Given that all "mirror updates" are performed via a worker through the service, this provides the wanted feature, but we don't have any interface to define the mirror yet. --HG-- branch : heptapod
-
Raphaël Gomès authored
--HG-- branch : heptapod
-
- 18 Nov, 2020 1 commit
-
-
Raphaël Gomès authored
This will be reverted once LFS support is implemented --HG-- branch : heptapod
-
- 25 Nov, 2020 1 commit
-
-
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
-
- 07 Oct, 2020 1 commit
-
-
Georges Racinet authored
In Heptapod, we'll want to pull from or push to remote Mercurial repositories, while keeping the capability to push a Mercurial project to a Git remote (currently possible as a side effect of our internal conversion to Git of `hg_git` projects). Another complication is that automatic *pull* Git mirroring is a proprietary feature of GitLab (available in starter). We don't want to interfere with the possibility that it would eventually land in Core, or that we could some day have a Start edition for Heptapod. This new column on the `RemoteMirror` model should give us the wanted flexibility with few risks of interference. It is to be understood on top of the existing push to Git feature. The values would be: - nil: nothing specific to Heptapod, hence actually a Git push - pull: Mercurial pull - push: Mercurial push --HG-- branch : heptapod
-
- 21 Nov, 2020 1 commit
-
-
Sushil Khanchi authored
--HG-- branch : heptapod
-
- 24 Nov, 2020 1 commit
-
-
Georges Racinet authored
it's necessary for functional tests to pass with `--heptapod-hg-native` on a fresh instance, since they aren't allowed by default. I'm not a fan of the comma-separated style, since that's using a different type for writes than what gets returned, but it seems to be the standard GitLab way. There's even a [cop for that](rubocop/cop/api/grape_array_missing_coerce.rb) --HG-- branch : heptapod
-
- 20 Nov, 2020 2 commits
-
-
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
-
Georges Racinet authored
Both are for #364, GitLab hooks in the native Mercurial case. --HG-- branch : heptapod
-
- 19 Nov, 2020 2 commits
-
-
Georges Racinet authored
Passing revisons that won't resolve and the like. --HG-- branch : heptapod
-
Georges Racinet authored
This is used notably in the Merge Request widget. It really needs to work, otherwise users wouldn't see any "Merge" button. Also to check that this is really Git `revA..revB`, hence Mercurial's `revB % revA`, not any kind of DAG range. --HG-- branch : heptapod
-
- 18 Nov, 2020 2 commits
-
-
Georges Racinet authored
For such long series (involving a merge from heptapod-stable that will also be published), an explicit merge changeset totally makes sense. - this will be tested with the base image hosted on our own Container Registry - contains a long list of fixes for Mercurial native repositories, making them usable for Heptapod 0.17.0 (passing the 'remote' subset of functional tests) --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
Again reducing our dependency and pull rate with respect to Docker Hub --HG-- branch : heptapod
-
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 1 commit
-
-
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
-
- 17 Nov, 2020 1 commit
-
-
Georges Racinet authored
First, we need to put #368 behind us. Second, adaptations for Mercurial repositories will in particular affect the main changed line in branch_check. --HG-- branch : heptapod
-
- 16 Nov, 2020 3 commits
-
-
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
-
Georges Racinet authored
It's been pointed to us that running `hg` to actually start a service may not be readily understood outside of the Mercurial community. --HG-- branch : heptapod
-
Georges Racinet authored
--HG-- branch : heptapod
-
- 15 Nov, 2020 4 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
More stuff dating back to pre-HDK times (no Rubocop in editor) --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 1 commit
-
-
Georges Racinet authored
The endpoint called by Heptapod Shell will now add this information, which in turn will be used by Shell to switch its `hg` subprocess to the appropriate mode (sending Hg SHAs notification to GitLab). --HG-- branch : heptapod
-