1. 26 Nov, 2020 1 commit
  2. 08 Oct, 2020 1 commit
  3. 25 Nov, 2020 3 commits
  4. 18 Nov, 2020 1 commit
  5. 25 Nov, 2020 1 commit
  6. 18 Nov, 2020 1 commit
  7. 07 Oct, 2020 1 commit
    • Georges Racinet's avatar
      remote_mirrors: add hg_mirror_type column · 952df9a233a9
      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
      952df9a233a9
  8. 21 Nov, 2020 1 commit
  9. 24 Nov, 2020 1 commit
    • Georges Racinet's avatar
      Setting allowed VCS types via API · e2b0e247a84a
      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
      e2b0e247a84a
  10. 20 Nov, 2020 2 commits
    • Georges Racinet's avatar
      Re-separate GitLab and Heptapod Workhorse versions · 0fd9ec6fa027
      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
      0fd9ec6fa027
    • Georges Racinet's avatar
      Bumping versions of Heptapod Shell and Workhorse · d92e171f9803
      Georges Racinet authored
      Both are for #364, GitLab hooks in the native
      Mercurial case.
      
      --HG--
      branch : heptapod
      d92e171f9803
  11. 19 Nov, 2020 2 commits
  12. 18 Nov, 2020 2 commits
    • Georges Racinet's avatar
      Merged Heptapod native mode support and CI/doc changes · eb08d99d5e61
      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
      eb08d99d5e61
    • Georges Racinet's avatar
      HgGitRepository: avoid exception on empty repo · dcc83c4464fc
      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
      dcc83c4464fc
  13. 17 Nov, 2020 2 commits
    • Georges Racinet's avatar
      Heptapod CI: hosting the base image for Heptapod builds · 1a6bd83cd776
      Georges Racinet authored
      Again reducing our dependency and pull rate with respect to
      Docker Hub
      
      --HG--
      branch : heptapod
      1a6bd83cd776
    • Georges Racinet's avatar
      BranchCheck: avoid transactional problem with Mercurial · 23bd45dee3c4
      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
      23bd45dee3c4
  14. 16 Nov, 2020 1 commit
  15. 17 Nov, 2020 3 commits
  16. 16 Nov, 2020 1 commit
  17. 17 Nov, 2020 1 commit
  18. 16 Nov, 2020 3 commits
    • 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
      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
      948dac54b949
    • Georges Racinet's avatar
      INSTALL_HEPTAPOD: sample hgitaly.service systemd unit · ae7538ebbffd
      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
      ae7538ebbffd
    • Georges Racinet's avatar
      INSTALL_HEPTAPOD: fixed typo in HGitaly command-line · 540c0202cd21
      Georges Racinet authored
      --HG--
      branch : heptapod
      540c0202cd21
  19. 15 Nov, 2020 4 commits
    • Georges Racinet's avatar
      Protected branches: deletion protection when no one allowed to push · 1290d9cfb0b7
      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
      1290d9cfb0b7
    • 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.
      
      --HG--
      branch : heptapod-stable
      b9859c4b49e1
    • Georges Racinet's avatar
      Repository Model: apply Rubocop rules · cdb21e4bda27
      Georges Racinet authored
      More stuff dating back to pre-HDK times (no Rubocop in editor)
      
      --HG--
      branch : heptapod-stable
      cdb21e4bda27
    • Georges Racinet's avatar
      Mercurial native mode: passing environment var to spawned `hg` · 8a49ca1ba8ba
      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
      8a49ca1ba8ba
  20. 14 Nov, 2020 3 commits
  21. 10 Nov, 2020 5 commits