Skip to content
Snippets Groups Projects
  1. Dec 19, 2020
    • Georges Racinet's avatar
      Git integration tests: rewrite with new fixtures and `amend_file()` · 2582c4af
      Georges Racinet authored
      In some cases, the variables shortcut are almost as long
      as the previously partly factorized setup, but this is clearer
      in many ways.
      
      An important feature is that we should be able to reuse many
      of these tests in the forthcoming changes for Mercurial-native
      Heptapod projects, for which hg-git won't be used any more, but
      we'll still have GitLab notifications etc.
      
      We don't need `make_main_repo()` any more, since `main_fixture` was
      created by duplicating its committing.
      2582c4af
    • Georges Racinet's avatar
      testhelpers: new `RepoWrapper.amend_file()` method · 6ab1afbd
      Georges Racinet authored
      It is fairly basic for now, yet already useful in this form.
      6ab1afbd
    • Georges Racinet's avatar
      testhelpers: class for fixtures involving hg-git GitLab mirroring · e6cce786
      Georges Racinet authored
      The new `GitLabMirrorFixture` will hold the two repositories
      and the notification interception mechanism.
      
      We demonstrate by rewriting only two tests, but the goal is
      to make all of them just use the new fixtures for better clarity
      and maintanibility.
      
      Another goal is to use this class directly in HGitaly comparison
      tests with Gitaly (hgitaly#35).
      
      The new class is mostly tested indirectly. A minor difference
      with the previous test is that it actually creates the Git repo
      (which hg-git would otherwise do anyway). This was felt to be
      clearer, and tests depending on this won't have to make special
      cases for when no mirroring actually occurred (can imagine that
      to happen with tests for error paths).
      e6cce786
    • Georges Racinet's avatar
      testhelpers: new `gitlab` module, adopting hooks patching. · bee861c7
      Georges Racinet authored
      Even tests that do not care about assertions about notifications
      sent to GitLab need this, because there is typically not a
      GitLab Rails application to send requests to.
      
      This is a base building block that will be useful in other
      contexts, such as HGitaly comparison tests with Gitaly.
      bee861c7
    • Georges Racinet's avatar
      bbbd984a
    • Georges Racinet's avatar
      testhelpers: split out a hg module · 0c33f04d
      Georges Racinet authored
      For better symmetry with upcoming Git helpers.
      
      We're maintaining compatibility by re-exposing at the package
      level.
      0c33f04d
    • Georges Racinet's avatar
      testhelpers: converted in a Python package · c8c21f9b
      Georges Racinet authored
      We're about to have it adopt some more utilities.
      c8c21f9b
  2. Dec 18, 2020
  3. Dec 16, 2020
    • Raphaël Gomès's avatar
      config: add option to never exchange bookmarks · bf548f18
      Raphaël Gomès authored
      Some repositories (particularly Octobus's `mercurial-devel` instance) do not
      want to exchange bookmarks, ever. This change applies to all exchange mechanisms
      relevant to Heptapod but was initially motivated by the new hg pull mirrors.
      bf548f18
  4. Dec 17, 2020
  5. Dec 15, 2020
    • Georges Racinet's avatar
      GitLab branches state: exposing with cache and missing marker · f4894147
      Georges Racinet authored
      This is the bare minimum needed so that downstream users such
      as HGitaly can leverage it.
      
      The final version should probably become a property on the
      repo instance, but that will require actually more work, because
      it's not immediately clear if the standard Mercurial tooling
      applies well in this quite special case, namely:
      
      - we don't want any invalidation to occur before the explicit
        write at the end of transaction, for consistency reasons:
        the very mission of the state file is to represent the state
        at the beginning of transaction.
      - we're working under the assumption that all writes to the
        repository will update the state file. This is true, yet
        very specific to the Heptapod server environment.
      
      
      It's fine for `read_gitlab_branches` to raise `FileNotFoundException`.
      Will have to see for other exceptions though.
      f4894147
  6. Dec 14, 2020
  7. Dec 12, 2020
    • Georges Racinet's avatar
      GitHandler: updating the GitLab branches state file · a5b46e78
      Georges Racinet authored
      Of course, all this back-and-forth conversion from Git SHAs
      to Hg SHAs is getting long. The goal at this point is merely
      to make it available right away to HGitaly.
      
      Later on we'll have to split the branch analysis logic, and we'll
      start having a handler for Mercurial native projects, that will
      eventually not convert to Git at all.
      a5b46e78
    • Georges Racinet's avatar
      State file for GitLab branches · 014d5f95
      Georges Racinet authored
      As explained in the long docstring, this represents the latest
      state of branches *transmitted* to GitLab, i.e. has to be considered
      the state at beginning of transaction if there is an ongoing one (used
      precisely to deduce changes to notify GitLab about) or the current
      state if there is no ongoing transaction (read-only case).
      
      The read-only case will be useful for HGitaly right away: instead
      of doing expensive computations for each branch read, it will
      leverage this file if available.
      014d5f95
    • Georges Racinet's avatar
      GitHandler tests: more assertions on notifications · 73809d34
      Georges Racinet authored
      These were long-standing TODOs.
      73809d34
    • Georges Racinet's avatar
      Future version will be 2.0.0 · bc840e7e
      Georges Racinet authored
      The change in configuration flags for multiple heads is
      a non backwards compatible change.
      bc840e7e
    • Georges Racinet's avatar
      Bookmarks: don't lift multiple heads protection · 8d755f36
      Georges Racinet authored
      Thanks to previous changes, the protection against multiple heads
      happens in `HeptapodGitHandler` instead of earlier in
      the transaction.
      
      We can thus stop lifting it when bookmarks are allowed,
      because the check now occurs once bookmarked
      heads have been taken out of the game.
      
      This is a boon for projects that track Git upstreams (like many
      components of Heptapod do, including the Rails application:
      they now can now use bookmarks to track their Git upstream
      branches and still be protected against multiple heads.
      8d755f36
    • Georges Racinet's avatar
      Test utils: expose path to required.hgrc · c38f7984
      Georges Racinet authored
      Necessary to test what happens with the default configuration.
      c38f7984
    • Georges Racinet's avatar
      Multiple heads: controlled by heptapod flag only. · 31b99ecf
      Georges Racinet authored
      Most users were using the core `experimental.single-head-pre-branch`
      only because Heptapod included it its "required" configuration.
      
      This is not the case any more, meaning we can let go
      of the monkeypatching introduced to avoid filtering obsolete heads
      twice.
      31b99ecf
    • Georges Racinet's avatar
      tests: no coverage needed for testing log interceptor · 94494e77
      Georges Racinet authored
      whether we use it or not depends on the testing needs,
      but it's not part of the main code anyway.
      94494e77
  8. Dec 04, 2020
    • Georges Racinet's avatar
      Heptapod CI: base image tag is now `default` · 04d44016
      Georges Racinet authored
      This was done in the stable branch, and gives us a nice uniformity.
      The `default` tag of the base image is ready for this.
      04d44016
    • Georges Racinet's avatar
      Heptapod CI: deriving tag of upstream image from hg branch · f8254617
      Georges Racinet authored
      This matches changes done in the base mercurial image so that its
      tag is now `default` instead of `latest`.
      
      At this point, the CI configuration of py-heptapod can be the same
      in its `stable` and `default` branches.
      f8254617
    • Georges Racinet's avatar
      Heptapod CI: proper base image for stable, and less jobs · 7e8e6205
      Georges Racinet authored
      We need to use the `stable` tag of the base image for the `hg-current`
      job. Indeed too bad we can't just propagate the hg branch name, maybe it's
      time to do something about (uniformity makes the stable branch mergeable
      into the default branch without fear)
      
      It doesn't make much sense to run the `hg-default` and `hg-stable`
      jobs for the stable branch of py-heptapod, which won't change Mercurial
      versions, unless hg-stable is for the same hg x.y as hg-current (currently
      not the case).
      7e8e6205
  9. Dec 03, 2020
    • Georges Racinet's avatar
      Start of new stable branch · 5bfeeac1
      Georges Racinet authored
      With the versioning scheme explained in heptapod#352, it
      doesn't make sense any more to have stable branches labelled after
      general Heptapod versions.
      
      With py-heptapod and semver, it's quite possible that we don't need
      to actually make default diverge from stable in some cycles. Still
      it will be convenient to have a clear reference. The alternative would
      be not to change, e.g., the HDK configuration, and then forget to update
      it once it becomes necessary.
      5bfeeac1
  10. Dec 02, 2020
Loading