1. 02 Nov, 2020 1 commit
  2. 01 Dec, 2020 1 commit
    • Georges Racinet's avatar
      GitLab::Shell: fixed reading Heptapod Version · d36b1d5b79e9
      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
      branch : heptapod
  3. 27 Nov, 2020 1 commit
  4. 28 Nov, 2020 3 commits
    • Georges Racinet's avatar
      Mercurial native projects: fix forwarding group conf inheritance · 8c0af5f12593
      Georges Racinet authored
      Predated the introduction of `Project#mercurial?`, obviously.
      branch : heptapod
    • Georges Racinet's avatar
      Mercurial native projects: backup default GitLab branch definition · 3038f0db68c4
      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.
      branch : heptapod
    • Georges Racinet's avatar
      Repos backups: clearly identify Wikis in failure logs · 873470b91e12
      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
      branch : heptapod
  5. 27 Nov, 2020 3 commits
  6. 26 Nov, 2020 1 commit
  7. 08 Oct, 2020 1 commit
  8. 25 Nov, 2020 3 commits
  9. 18 Nov, 2020 1 commit
  10. 25 Nov, 2020 1 commit
  11. 18 Nov, 2020 1 commit
  12. 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
      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
      branch : heptapod
  13. 21 Nov, 2020 1 commit
  14. 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)
      branch : heptapod
  15. 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.
      branch : heptapod
    • 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.
      branch : heptapod
  16. 19 Nov, 2020 2 commits
  17. 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)
      branch : heptapod
    • 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.
      branch : heptapod
  18. 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
      branch : heptapod
    • 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.
      branch : heptapod
  19. 16 Nov, 2020 1 commit
  20. 17 Nov, 2020 3 commits
  21. 16 Nov, 2020 1 commit
  22. 17 Nov, 2020 1 commit
  23. 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
      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
    • 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.
      branch : heptapod
    • Georges Racinet's avatar
      INSTALL_HEPTAPOD: fixed typo in HGitaly command-line · 540c0202cd21
      Georges Racinet authored
      branch : heptapod
  24. 15 Nov, 2020 3 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
      branch : heptapod-stable
    • 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
    • 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)
      branch : heptapod-stable