Read about our upcoming Code of Conduct on this issue

This instance will be upgraded to Heptapod 0.28.0 on 2022-01-18 at 14:00 UTC+1 (a few minutes of down time)

  1. 13 Dec, 2020 1 commit
    • Georges Racinet's avatar
      Bitbucket import: removed most of the code · fdb960fc35b5
      Georges Racinet authored
      There aren't Mercurial repositories to import from Bitbucket
      any more: our divergence with upstream on this is now just a
      Removal is partial in order not to jeopardize the installation
      of 0.18.0rc1 on foss.h.n (second OAuth, worker queue registration
      etc.). In all cases, behaviour on such configurations will be
      tested and adjusted before release.
      branch : heptapod
  2. 02 Dec, 2020 1 commit
  3. 26 Nov, 2020 1 commit
  4. 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
  5. 15 Nov, 2020 2 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
  6. 03 Nov, 2020 1 commit
  7. 02 Nov, 2020 1 commit
  8. 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
  9. 28 Nov, 2020 2 commits
    • 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
  10. 27 Nov, 2020 2 commits
  11. 30 Oct, 2020 3 commits
  12. 21 Oct, 2020 1 commit
  13. 14 Oct, 2020 1 commit
  14. 25 Nov, 2020 3 commits
  15. 18 Nov, 2020 1 commit
  16. 21 Nov, 2020 1 commit
  17. 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
  18. 20 Nov, 2020 1 commit
    • 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
  19. 18 Nov, 2020 1 commit
    • 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
  20. 17 Nov, 2020 1 commit
    • 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
  21. 16 Nov, 2020 1 commit
  22. 17 Nov, 2020 3 commits
  23. 16 Nov, 2020 1 commit
  24. 15 Nov, 2020 1 commit
  25. 14 Nov, 2020 3 commits
  26. 09 Nov, 2020 4 commits
    • Georges Racinet's avatar
      HGitayRepository: fixing Diff invocations · 92500bee7f38
      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
      branch : heptapod
    • Georges Racinet's avatar
      Repository: SHA conversion with fallback · 2605fa2b1a16
      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).
      branch : heptapod
    • Georges Racinet's avatar
      HGitalyRepository: fix cached_exists? and conversions for vcs-cloned · b188426a2147
      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.
      branch : heptapod
    • Georges Racinet's avatar
      Blob,Tree: incoming "sha" can be any revision · a3ed118369a6
      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'
      branch : heptapod