1. 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
  2. 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
  3. 26 Sep, 2020 8 commits
  4. 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
  5. 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
  6. 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
  7. 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
  8. 03 Sep, 2020 3 commits
    • Georges Racinet's avatar
      Added tag heptapod-0.16.0.pre for changeset d73bf9d8fbd2 · 5d56556da28e
      Georges Racinet authored
      --HG--
      branch : heptapod
      5d56556da28e
    • Georges Racinet's avatar
      Marking as being 0.16.0.pre · d73bf9d8fbd2
      Georges Racinet authored
      The main purpose is to produce a tag that will be used to
      validate the new build/release system (see #338 and
      #339).
      
      It also makes sense to label the present revision in this way,
      as we've completed the first big task of the 0.16 series, namely
      moving to GitLab 13.3
      
      --HG--
      branch : heptapod
      d73bf9d8fbd2
    • Georges Racinet's avatar
      Heptapod CI: job to produce and push heptapod-rails tarballs · c1c4a4f5926a
      Georges Racinet authored
      The job is manual and non-blocking if from a regular push or
      from the Web UI.
      
      It is in a separate stage because it felt just wrong to label
      it as 'test'.
      
      For the time being, we're making it not depend on tests to pass,
      because that's too much of a pain while we are working on the
      packaging itself. We may want that in the future, though, for
      final validation before release.
      
      Closes: #339
      
      --HG--
      branch : heptapod
      c1c4a4f5926a
  9. 29 Aug, 2020 2 commits
    • Georges Racinet's avatar
      Heptapod CI: changing cache key · 250158f844b4
      Georges Racinet authored
      Various dependencies differ between GitLab 13.1.4 and 13.3.0,
      we don't want the caches to play back-and-forth depending on the
      branch.
      
      --HG--
      branch : heptapod
      250158f844b4
    • Georges Racinet's avatar
      Merge with upstream GitLab v13.3.0 and adaptation · b424a93fdfc0
      Georges Racinet authored
      For the first time, we were able to get functional tests
      to work right away in the same commit, thanks to the inner
      (RSpec) tests.
      
      Points of attention:
      
      - `HgAccess`:
      
        + our `user_can_push?` method was creating a loop due to a
          method with the exact same name appearing in the `GitAccess` base class.
          Solved by prefixing it with `hg_`, just to mark specificity, but a better
          naming would be in order.
        + in `GitAccess`, the command is now an instance variable, so that
          a bunch of methods are now without arguments, and we had to
          correct `HgAccess` accordingly.
      - some repository removals don't go through `Gitlab::Shell#remove_repository`
        any more, and are instead directly handled by the Repository method
      - Bitbucket (Mercurial) importer is ported, but it should really be dropped,
        now that Bitbucket has no Mercurial repos any more.
      - DB migration state for new installations is now stored differently,
        with one file per migration whose content is the sha256 of the migration number
        (created those for Heptapod migrations, 20190816151222 and 20200712154738).
      - The upstream base CI image has a minor change, that we'll have to
        reflect into our own images
      
      Next move will be more complicated in pure terms of
      version control: `master` and released versions have become
      unrelated for a long time now.
      
      --HG--
      branch : heptapod
      b424a93fdfc0
  10. 27 Aug, 2020 4 commits
    • Georges Racinet's avatar
      Forwarding actual permissions to Mercurial processes · 4c45dfe84231
      Georges Racinet authored
      Closes #334
      
      Normally, the abstraction layers in GitLab mean that the Project
      should not be accessible from the low level repository. However,
      we need it to pass it down to the `hg` processes. Doing it in
      `hg_env_for_write` is the way to make it really robust, since all
      write operations basically have to use it.
      
      To mitigate somewhat this breach of abstraction, we make the
      attribute writable only, and we give it a more specific name than
      just '@project'. Aesthetically, it would be better to store only
      a factory for the `UserAccess` instance that we really need, but
      that could be done separately.
      
      This required running some of `HgAccess` RSpec tests with empty
      repositories, because in them, the project owner does not have enough
      rights to create a first commit any more, and there's not even
      an admin user around for that.
      
      --HG--
      branch : heptapod
      4c45dfe84231
    • Georges Racinet's avatar
      HgGitRepository: removed duplication · 4fb9222b604b
      Georges Racinet authored
      We still have a deprecated compatibility alias, and the
      rebase tests prove that it works.
      
      --HG--
      branch : heptapod
      4fb9222b604b
    • Georges Racinet on mutations.racinet.fr's avatar
      d1aba8b71579
    • Georges Racinet on mutations.racinet.fr's avatar
      HgGitRepository: attribute to skip Git hooks for tests · db821ec4ea3f
      This new attribute is not meant to be used in any other context
      than RSpec tests, whence the name. It allows us to use higher
      level methods such as `multi_action` in tests setups and will be
      necessary to test them.
      
      Upstream does something similar with no need to involve the tested code:
      they launch Gitaly server with the `GITALY_TESTING_NO_GIT_HOOKS` environment
      variable.
      
      --HG--
      branch : heptapod
      db821ec4ea3f
  11. 26 Aug, 2020 3 commits
  12. 25 Aug, 2020 4 commits
  13. 24 Aug, 2020 1 commit
    • Georges Racinet's avatar
      Unauthorized commit creation from Web UI: user feedback · d6cf46bd51c4
      Georges Racinet authored
      As already stated, it would be nicer not to display file edit
      buttons if the user actually can't create a commit in the given
      branch, but at least this gives a proper 403 page and gives users
      a proper explanation.
      
      --HG--
      branch : heptapod-stable
      d6cf46bd51c4