1. 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
      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
  2. 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
      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
  3. 01 Nov, 2020 1 commit
    • Georges Racinet's avatar
      hgignore: ignoring the shared/ directory · 9f176b840e4e
      Georges Racinet authored
      It only has a bunch of '.gitkeep' files to ensure its subdirectories
      are present, and is a major source of status pollution, being used
      for data files.
      
      --HG--
      branch : heptapod-stable
      9f176b840e4e
  4. 30 Aug, 2020 1 commit
    • Georges Racinet's avatar
      Heptapod CI: dedicated image tag for heptapod-stable · df057c730aa3
      Georges Racinet authored
      The current heptapod branch will use a new testing image with
      new versions of many things, notably of the upstream base image,
      so we need separate images for our two development branches.
      
      --HG--
      branch : heptapod-stable
      df057c730aa3
  5. 26 Oct, 2020 6 commits
  6. 24 Sep, 2020 4 commits
    • Georges Racinet's avatar
      Merge Requests: ability to change source branch via Web UI · 3a77d1e79440
      Georges Racinet authored
      This needs a JavaScript change, that we're performing trying to minimize
      impact (still storing the select on $this) while avoiding code duplication.
      
      We're trying to get duplication in the HAML template low, but there's only
      so much that can be done there.
      
      --HG--
      branch : heptapod-stable
      3a77d1e79440
    • Georges Racinet's avatar
      Merge Requests: allowing to change source branch, API only · 8705522bb21d
      Georges Racinet authored
      This is the inner part of #138: we have to lift the
      restrictions against the change of that column precisely,
      expose it in the API, and do the post-treatment (system note,
      cancellation of automatic merge).
      
      The diff invalidation in app/models/repository.rb was already
      taking this case into account.
      
      --HG--
      branch : heptapod-stable
      8705522bb21d
    • Georges Racinet's avatar
      HgGitRepository: avoid calling Gitaly for each SHA conversion · 7cd3bea5339a
      Georges Racinet authored
      Spotted by the rate limit on Gitaly calls. We're simply caching
      the result if it's positive.
      
      --HG--
      branch : heptapod-stable
      7cd3bea5339a
    • Georges Racinet's avatar
      HgGitRepository: complying to the 'return nil' cop · 49c095c70b60
      Georges Racinet authored
      Too bad if I personally consider it better style to make that
      we're return nil explicit in case of methods actually
      expected to return something (clear intent, and
      nicer to people not used to the language).
      
      --HG--
      branch : heptapod-stable
      49c095c70b60
  7. 10 Sep, 2020 1 commit
    • Georges Racinet's avatar
      Markdown renderings: lookup for Mercurial short nodes · 31146d7c450d
      Georges Racinet authored
      The `CommitReferenceFilter` class is the one responsible for
      the rendering.
      
      We're *adding* resolution of truncated Mercurial Node ids for
      the case of the `hg_git` VCS type, relying on the existing
      map of full Mercurial SHA (Node id) to Git SHA.
      
      This is very inefficient, and proper calls with low startup
      overhead to a persistent Mercurial nodemap would do much better
      above a certain repository size (persistent nodemap is provided
      by Rust native extensions, and low overhead would be achieved only
      by a fastpath without Python or a long-running process, such as
      HGitaly)
      
      While the `Git::Commit.batch_by_oid` method
      doesn't seem to be called except from the `#commits_by` method of the
      `Repository` model, the latter is used in several places
      of the application, with risks of breakage and/or severe performance
      degradation. For `hg_git` VCS type, most callers don't need the Mercurial
      resolution. That's why we're executing the new lookup only if
      the new `hg_full_resolution` argument is set to `true`.
      
      Preliminary performance analysis (non scientific, on my workstation)
      shows that in the 100k changesets range (pypy repo) this naive lookup takes
      about 30ms, whereas `hg log -T` is in the 100-200ms ballpark.
      Around 500k changesets (mozilla-central repo), times have the same order
      of magnitude (around 100-200ms again). To insist, this is with the hg startup
      overhead and without the Rust persistent nodemap (would take less than 1ms).
      We fully expect the current hg<->git maps to be an unbereable performance
      problem in Heptapod anyway around 500k to 1M changesets anyway, only solved
      by HGitaly.
      
      All in all, the performance question seems to be acceptable in the current
      inefficient context *for Note rendering*.
      HGitaly would provide an efficient RPC call anyway.
      
      --HG--
      branch : heptapod-stable
      31146d7c450d
  8. 27 Sep, 2020 1 commit
    • Georges Racinet's avatar
      Mercurial SHA: fixing label in some commit lists · 0368ff9b95c8
      Georges Racinet authored
      This one can be seen in Merge Request commits page.
      The clipboard button was doing the right thing, but the
      accompanying label (most of what users see) was the Git SHA.
      
      --HG--
      branch : heptapod-stable
      0368ff9b95c8
  9. 26 Sep, 2020 8 commits
  10. 22 Sep, 2020 1 commit
    • Georges Racinet's avatar
      Made Heptapod 0.16 the new stable series · d3c179ff83c7
      Georges Racinet authored
      Technically, this is a merge from the heptapod branch,
      right after it's been merged into the heptapod-0-16 branch
      to cut the Heptapod 0.16.0 release.
      
      --HG--
      branch : heptapod-stable
      d3c179ff83c7
  11. 21 Sep, 2020 4 commits
    • Georges Racinet's avatar
      Heptapod branding on error pages · 3e7385cdd3c1
      Georges Racinet authored
      These are served directly by workhorse (or nginx if workhorse
      is itself not available)
      
      --HG--
      branch : heptapod
      3e7385cdd3c1
    • Georges Racinet's avatar
      Heptapod logos: changing the 210x210 SVG logo · 2e113d7016c5
      Georges Racinet authored
      It is not completely obvious to me what is derived from that one.
      
      --HG--
      branch : heptapod
      2e113d7016c5
    • Georges Racinet's avatar
      Heptapod favicon · 7df630996701
      Georges Racinet authored
      At least on a HDK modified to run in production mode, this
      puts a Heptapod favicon instead of the GitLab one.
      
      --HG--
      branch : heptapod
      7df630996701
    • Georges Racinet's avatar
      Packaging: pulling tag definition before tarball creation · dacd39dfd1f8
      Georges Racinet authored
      Closes #345. The selective pull we're adding should be
      enough in most cases with our current branching strategy.
      
      Since we can't really test it without polluting the tags,
      and it's not a really big problem if it doesn't work, we're
      allowing the pull to fail. This can be made stricter in a
      follow-up.
      
      --HG--
      branch : heptapod
      dacd39dfd1f8
  12. 10 Sep, 2020 4 commits
    • Georges Racinet's avatar
      Markdown rendering for links to Mercurial changesets · 42a5f760c1a1
      Georges Racinet authored
      This fixes the rendering of all links to Mercurial changesets in
      Markdown (#342), because the changed method is the one called from
      `lib/banzai/filter/abstract_reference_filter`.
      
      In particular, the "system note" displaying additional commits in MRs
      are actually rendered server side from Markdown produced by
      `SystemNotes::CommitService#commits_list`.
      
      This doesn't change the lookup, i.e., the SHA prefix to render is still
      the Git one.
      
      Also, the rendering of `Note` is persisted in the database, in the
      `note_html` column, so this change doesn't apply to existing Notes.
      We could have a background migration for this, or simply a mass
      invalidation if that is suitable.
      
      --HG--
      branch : heptapod
      42a5f760c1a1
    • Georges Racinet's avatar
      HEPTAPOD_CHANGELOG: current developments for 0.16.0 · 00b6bda01c9d
      Georges Racinet authored
      --HG--
      branch : heptapod
      00b6bda01c9d
    • Georges Racinet's avatar
      HEPTAPOD_CHANGELOG: imported from 0.15.3 · c93f28dd4d8a
      Georges Racinet authored
      Of course the revisions of that file that matter are those
      from the release branches, but sometimes we want to work on
      it ahead, and it looked like an error to have nothing after 0.13
      
      --HG--
      branch : heptapod
      c93f28dd4d8a
    • Georges Racinet's avatar
      Rendering Mercurial Node IDs in Repository > Graph · c9899e294f67
      Georges Racinet authored
      See #344
      
      This is a reviving of acc9c69295de, whose JavaScript part
      was unintentionally reverted in the big churn for the jump
      to GitLab 12.10 (05c3e70b82f8).
      
      It wouldn't have worked anyway before #338, except for source installations.
      
      --HG--
      branch : heptapod
      c9899e294f67
  13. 09 Sep, 2020 4 commits
    • Georges Racinet's avatar
      Bumping hg-evolve to 10.0.2 · 010089c31626
      Georges Racinet authored
      This version just got released, with at least a fix for a
      Python 3 problem (bug6390) that was first seen in Heptapod
      context
      
      --HG--
      branch : heptapod
      010089c31626
    • Georges Racinet's avatar
      Heptapod CI: avoiding duplicate rspec jobs. · a9796784cbbe
      Georges Racinet authored
      We'd rather not use Detached Merge Request pipelines as in earlier
      GitLab versions than to launch these heavy jobs twice.
      
      As explained in the comment, we really want the `rspec` job to run
      for pushes not MR related.
      
      --HG--
      branch : heptapod
      a9796784cbbe
    • Georges Racinet's avatar
      Repository model: fixed import method if project is nil · 5ec5e5e5f109
      Georges Racinet authored
      This was spotted by the development setup seeding snippets.
      Probably the novelty in GitLab 13.3 is to go straight through
      this instead of `Gitlab::Shell`. The point is that a Repository
      is not necessarily tied to a Project any more, it has a container,
      which can itself have a Project, or not. Snippets can exist
      independently of any Project.
      
      --HG--
      branch : heptapod
      5ec5e5e5f109
    • Georges Racinet's avatar
      Mercurial 5.5.1 · 11a0ca43d34c
      Georges Racinet authored
      This bugfix version was released after we started the Heptapod 0.16
      development cycle, with a bugfix in the HTTP subsystem:
      https://bz.mercurial-scm.org/show_bug.cgi?id=6356
      
      --HG--
      branch : heptapod
      11a0ca43d34c
  14. 03 Sep, 2020 1 commit