1. 09 Oct, 2020 1 commit
    • Georges Racinet's avatar
      HgGitRepository: low level hg_tag method · 74b64d425d85
      Georges Racinet authored
      This is for now mostly intended as a helper for tests.
      We're using one of the HGitaly tags test to make sure it works,
      and in turn that test gets simplified.
      There's a catch: `hg_git_repository.hg_tag` would not
      work before `subject` has been used at least once, so that the
      repository is indeed initialized on disk.
      If we were in need to use `hg_git_repository` here, we'd have
      to switch to `subject!` instead of just `subject`.
      branch : heptapod
  2. 07 Oct, 2020 3 commits
  3. 03 Oct, 2020 7 commits
  4. 02 Oct, 2020 1 commit
    • Georges Racinet's avatar
      Heptapod CI: verbose RSpec output · 736d5195c5fb
      Georges Racinet authored
      This switches RSpec to the "documentation" format (groups and
      example names), which helps being sure that an expected test has
      really been run.
      branch : heptapod
  5. 28 Sep, 2020 3 commits
  6. 30 Sep, 2020 1 commit
  7. 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.
      branch : heptapod-stable
    • 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.
      branch : heptapod-stable
    • 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.
      branch : heptapod-stable
    • 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).
      branch : heptapod-stable
  8. 14 Sep, 2020 3 commits
    • Georges Racinet's avatar
      tests: fixing HGitaly access in CI · 64a35f7bc6bd
      Georges Racinet authored
      Even though, we have a default value for `hgitaly_address` in
      `GitalyClient::StorageSettings`, some test contexts don't use
      it (mocking of similar). This leads to errors even before
      HGitaly tests actually start.
      The configuration method depends on the installation type:
      - in the HDK, we already have an explicit value
      - in the CI, the whole `gitlab.yml` config is copied from
      - thanks to progress made on #337, it's fair to suppose
        Omnibus will take care of Docker containers by the time HGitaly is
        ready for alpha usage
      So, at this point, getting rid of the default value would be only
      consistent. Still we'll do that in a follow-up.
      branch : heptapod
    • Georges Racinet's avatar
      Hgitaly: repository class, using the Ref service · d08e4ed93de0
      Georges Racinet authored
      For now, the `HGitalyRepository` inherits from `HgGitRepository`,
      so that we can gradually transition.
      The granularity of the transition is at the service class level,
      and we start the movement by passing the expected `vcs: 'hg'`
      parameter to `GitalyClient::RefService`.
      The RSpec test in turn validates the round-trip with HGitaly,
      as an absolute expected result, as well as a comparision with
      the value returned by `HgGitRepository`.
      This particular example demonstrates the need for such an approach:
      hgitaly!3 was actually needed for the test to pass.
      branch : heptapod
    • Georges Racinet's avatar
      HGitaly: introduced 'VCS-qualified' storage for dispatching · 72870615113f
      Georges Racinet authored
      Several options have been considered to actually dispatch Gitaly
      requests to HGitaly server. The main problem is that each method
      of service classes such as ``Gitlab::GitalyClient::RefService` all go
      through the generic `GitalyClient.call`, passing only the `storage`
      1. use a naming convention on the storage name
      2. change the call sites for all service classes to pass a
         new optional `vcs` parameter
      3. introduce a new `vcs` property of storages, and use
         different storages for Mercurial repositories, with
         a `hg_default` storage by default.
      None of these was completely satisfactory, we settled on 1.
      The principle is that *internally*, the service class will
      pass `hg:default` instead of just `default` to indicate that
      the request should be dispatched to a HGitaly server. The
      VCS-qualified storage name is used as key in the connection pool,
      without any change of the pool logic: for the pool it looks as
      a different storage configuration.
      This VCS-qualified storage name won't leak in upper layers: the
      future `HGitalyRepository` class will instantiate the service class
      with the new `vcs` named argument, as introduced here in
      `RefService`. In particular, the VCS-qualified storage name won't
      appear in configuration, and conflicts are impossible because ':'
      is forbidden as storage name in configuration.
      This means that we'll have to implement each service fully
      completely before we expose them to upper layers, and that is
      probably fine for now. We could make a few exceptions if needed
      Approach 2. is the one my very first experiment relied on. Beside
      being cumbersome, it has the flaw of not affecting newly introduced
      RPCs automatically, while maximizing the potential of uninteresting
      Approach 3. would make the eventual transition from `hg_git` projects
      to `hgitaly` projects harder, forcing us notably to implement all services
      or add again a per-service logic, as we actually do already here with
      the `vcs` optional argument in the service class initializer. It would
      also currently force us to use the same path in the `default` storage
      and the `hg_default` storage. Finally, it would require more user interaction,
      that can be considering as pushing a naming convention to the user and admin
      branch : heptapod
  9. 22 Sep, 2020 1 commit
  10. 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)
      branch : heptapod
    • 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.
      branch : heptapod
    • 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.
      branch : heptapod
    • 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
      branch : heptapod
  11. 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
      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.
      branch : heptapod-stable
  12. 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.
      branch : heptapod-stable
  13. 26 Sep, 2020 8 commits
  14. 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.
      branch : heptapod-stable
  15. 10 Sep, 2020 1 commit
    • 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
      In particular, the "system note" displaying additional commits in MRs
      are actually rendered server side from Markdown produced by
      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.
      branch : heptapod