Read about our upcoming Code of Conduct on this issue

  1. 13 Dec, 2020 5 commits
  2. 06 Dec, 2020 1 commit
    • Georges Racinet's avatar
      HgitalyRepository tests: remove useless includes · 9e6d387532db
      Georges Racinet authored
      These were copied over from other tests and are of no use in
      that one (`Term` is about end-user terms acceptance, just
      to underline how far that is from the concerns of this test).
      branch : heptapod-stable
  3. 05 Dec, 2020 3 commits
    • Georges Racinet's avatar
      RSpec hg_access_protected_branches: removed lengthy setup · 611aad7f35ed
      Georges Racinet authored
      It turns out that these tests don't need the branches to actually
      exist. This gets the time to run this RSpec file down from 10
      minutes to less than 4 on my development workstation.
      That is enough to make sharding meaningful.
      Of course that raises the question whether they test anything,
      since some expected Forbidden could actually now be raised for
      the wrong reason. There is the case of the
      `safe_commit_for_new_protected_branch?` where one checks that
      protected branch rules are applied even if the commit actually
      creates the protected branch (through wildcard protection,
      that is indeed possible), but this is not currently covered,
      although it should.
      In other words actual coverage is no worse, and we should add
      new tests for the cases that aren't strongly covered,
      (perhaps UPSTREAM).
      The empty repo is a special case, but the general factory fixture
      takes care of that.
      branch : heptapod-stable
    • Georges Racinet's avatar
      RSpec tests for hg_access: using an empty repo for main tests · fc0da2f09a87
      Georges Racinet authored
      Thanks to this, the running time goes down from about 3mn to
      1mn and 50s on my system.
      The LFS tests are probably irrelevant: the day we activate Mercurial's
      version of LFS, we will certainly have to perform other types of checks.
      But then, they will perhaps serve as reminders that there is
      something to adapt.
      branch : heptapod-stable
    • Georges Racinet's avatar
      RSpec tests for hg_access: split in two · 84b0544435e7
      Georges Racinet authored
      The tests involving protected branches are likely to have different
      setup needs that the other. The bad news is that it's unbalanced:
      tests for protected branches take 10mn on my system, the others
      `hg_access_main_spec.rb` amount for just 3mn.
      branch : heptapod-stable
  4. 22 Nov, 2020 1 commit
  5. 20 Nov, 2020 1 commit
  6. 16 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Branch acces checks: direct identification of legit merges · 948dac54b949
      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
      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.
      branch : heptapod-stable
  7. 15 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Restore branch protection for Mercurial · b9859c4b49e1
      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.
      branch : heptapod-stable
  8. 03 Nov, 2020 1 commit
  9. 30 Oct, 2020 2 commits
  10. 21 Oct, 2020 1 commit
  11. 14 Oct, 2020 1 commit
  12. 25 Nov, 2020 1 commit
  13. 19 Nov, 2020 2 commits
  14. 09 Nov, 2020 2 commits
  15. 08 Nov, 2020 6 commits
    • Georges Racinet's avatar
      HGitalyRepository: Git-based list_last_commit_for_tree · e77cd6a5f21f
      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.
      branch : heptapod
    • Georges Racinet's avatar
      Tree: transitional implementation for Mercurial native repo · e77d525616cd
      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.
      branch : heptapod
    • Georges Racinet's avatar
      Blob: transitional implementation for native Mercurial repos · 6db10a1faece
      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.
      branch : heptapod
    • Georges Racinet's avatar
      HGitalyRepository: simplifying existing test after proper impl · a121b868324d
      Georges Racinet authored
      This is what the removed TODO was asking for.
      branch : heptapod
    • Georges Racinet's avatar
      HGitalyRepository: RSpec test for commit() · e78e257b8228
      Georges Racinet authored
      branch : heptapod
    • Georges Racinet's avatar
      HGitalyRepository RSpec: complying to Rubocop · bb8e3fb5e4ae
      Georges Racinet authored
      branch : heptapod
  16. 28 Oct, 2020 1 commit
  17. 30 Oct, 2020 3 commits
    • Georges Racinet's avatar
      Hgitaly Client spec: proper description · ab3f23fbc763
      Georges Racinet authored
      branch : heptapod
    • Georges Racinet's avatar
      HgGitRepository spec: adding a missing tear down · 604d53d6b822
      Georges Racinet authored
      That should spare us some headaches down the road
      branch : heptapod
    • Georges Racinet's avatar
      RSpec HGitalyRepository: fixes for hgsha_from_sha now being identity · 23494d896c42
      Georges Racinet authored
      Since the HGitaly `CommitService` is not in use yet, the `commit` method
      of `HGitalyRepository` still returns the Git commit converted from the
      Mercurial commit. Before we changed `hgsha_from_sha` to just return the
      incoming SHA for HGitalyRepository (which is eventually the proper behaviour),
      we had it actually converting to Mercurial (as with `HgGitRepository`).
      Since that's not the case any more, we have to use another way to
      find the Mercurial SHA.
      Also, in the tag case, the lazyness was making *both* SHAs being for
      the changeset creating the tag and its Git counterpart, because they
      were evaluated after tag creation. The simples solution here is to make
      it imperative.
      branch : heptapod
  18. 25 Oct, 2020 2 commits
    • Georges Racinet on's avatar
      Commit: introducing hpd_display_id · b10c60a26265
      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.
      branch : heptapod
    • Georges Racinet on's avatar
      archive_sha: fixing HGitalyRepository · e457db6b841d
      The position of the overriding method was just wrong. This went
      unnoticed because the Mercurial archive feature is for now tested
      with HgGitRepository only.
      branch : heptapod
  19. 26 Oct, 2020 1 commit
  20. 25 Oct, 2020 1 commit
  21. 19 Oct, 2020 2 commits
  22. 18 Oct, 2020 1 commit
    • Georges Racinet's avatar
      HgGitRepository#hg_pull · 667641b1a538
      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.
      branch : heptapod