1. 26 Nov, 2020 1 commit
    • Georges Racinet's avatar
      DockerHeptapod: Fixed SSH params · a9cbd203532d
      Georges Racinet authored
      Now that it inherits from OmnibusHeptapod, it had
      the hardcoded expected `git@localhost`, which isn't
      appropriate because DockerHeptapod is meant to be
      used from outside the container (and OmnibusHeptapod can
      be used from inside the container)
      a9cbd203532d
  2. 24 Nov, 2020 5 commits
  3. 25 Nov, 2020 1 commit
  4. 24 Nov, 2020 1 commit
  5. 19 Nov, 2020 4 commits
    • Georges Racinet's avatar
      Mercurial native: forbid closing of default GitLab branch · c6f0710241f7
      Georges Racinet authored
      With the native mode, something pushed is pushed. In that case
      if we don't want a closing changeset of the GitLab branch,
      we have to prevent pushing it in the first place.
      
      People can always change the default branch setting if needed
      c6f0710241f7
    • Georges Racinet's avatar
      Mercurial native: different rules for implicit bookmark push · a46bd63cda3e
      Georges Racinet authored
      For native repos, the shadowing happens at read time, so we
      can't make a difference between sliding (not a new bookmark)
      or not.
      
      Also, we cannot just let the bookmark at a previous position
      for the non-shadowed case of the default GitLab branch. This
      latter case is done identically for non-native repos because
      it was arguably a logical discrepancy.
      a46bd63cda3e
    • Georges Racinet's avatar
      Mercurial native mode: case where topic still visible after publication · 13eb36a56335
      Georges Racinet authored
      The branchmap rules make it so that if it's useful for visualisation
      of instabilities, in stack topics case, the older one is still
      visible after publication (because it's base of the one that now
      has to be rebased).
      
      Hoping this can change at some point in the future, though.
      13eb36a56335
    • Georges Racinet's avatar
      Mercurial native: introspect at Project level · dc2a28b750f8
      Georges Racinet authored
      For the very few tests that need to make a difference, it's
      best not to assume we will use a global flag available on
      the Heptapod project forever. It could very well depend on
      the given project.
      dc2a28b750f8
  6. 17 Nov, 2020 1 commit
  7. 14 Nov, 2020 1 commit
  8. 03 Nov, 2020 10 commits
  9. 17 Nov, 2020 1 commit
  10. 31 Oct, 2020 1 commit
  11. 29 Oct, 2020 3 commits
  12. 15 Oct, 2020 2 commits
  13. 12 Oct, 2020 1 commit
    • Georges Racinet's avatar
      New `--heptapod-hg-native` option · b2a5da28ceb5
      Georges Racinet authored
      This option makes the functional tests create Mercurial native
      projects instead of the default type (currently `hg_git`).
      
      Hence it will be the main tool to validate HGitaly related
      developments. Later on, we might want to introduce dedicated
      CI jobs. Switching to parametrization can also be considered,
      but it wouldn't change so much in CI, because we now have tests
      sharding.
      
      The new flag is stored on the `Heptapod` object, for lack of
      better choice in the short term (arguably, that's not a property
      of the Heptapod server).
      b2a5da28ceb5
  14. 06 Oct, 2020 4 commits
    • Georges Racinet's avatar
      Fixing flake8 and forcing the job in CI. · 56961c493a41
      Georges Racinet authored
      I *kwew* that this job not running on detached MR pipelines was
      going to be a problem. We can live with duplication of that job.
      56961c493a41
    • Georges Racinet's avatar
      Omnibus: stop hardcoding server-side path to hg · 55b1ee0b3b1b
      Georges Racinet authored
      For server-side operations, we should use the one provided by
      the server, obviously.
      
      The immediate need is that it varies amongst installation types
      With The new Omnibus packaging method (omnibus-heptapod!3)
      for Heptapod 0.17, it changes from /usr/local/bin (expected to be on PATH)
      to /opt/gitlab/embedded/bin.
      
      There are several TODOs:
      
      - read `hg_executable` from config, with remote instances being
        the only exceptions (but these wouldn't call server-side subprocesses
        from the tests).
      - provide a direct helper method on `Heptapod`
      - do the same for Git
      55b1ee0b3b1b
    • Georges Racinet's avatar
      git: new CLI option for client-side executable · ee0c40e91d6a
      Georges Racinet authored
      In 7a354d699944, we had the `heptapod` fixture carry the path
      to the client-side Git executable, but that creates confusion
      between the client and server sides (actually more manifest with
      Mercurial, but both should be handled in the same way).
      
      Now we make the client-side Git executable path work as for
      Mercurial, with a command line option and centralization in the
      `utils.git` module.
      
      Finally, we refactor both `utils.git` and `test_ssh` so that the
      latter can use the standard classmethod of `git.LocalRepo`.
      ee0c40e91d6a
    • Georges Racinet's avatar
      hg: new CLI option for client-side executable · 6397162194d8
      Georges Racinet authored
      This seems to be necessary for CI tests inside the Docker
      container, because /opt/gitlab/omnibus/bin is not on the PATH
      of the `git` user.
      6397162194d8
  15. 05 Oct, 2020 4 commits
    • Georges Racinet's avatar
      OmnibusHeptapod: fixing DevToolsActivePort chrome driver problem · fa268a4c73e9
      Georges Racinet authored
      Without this, the tests may crash with the
      "DevToolsActivePort file doesn't exist" error upon initialization
      of ChromeDriver.
      
      Many resources I could find about this are in a context when
      the tests are run as `root`, as I did in the first experiments.
      
      But it can happen also if running a non-privileged user, such
      as `git` in our case.
      
      Of course `--no-sandbox` wouldn't be acceptable for systems
      not entirely dedicated to the task, as is the case with
      `OmnibusHeptapod`, but not `DockerHeptapod` (in the latter,
      the web driver is on the user's system, not in the container).
      
      --HG--
      branch : stable
      fa268a4c73e9
    • Georges Racinet's avatar
      OmnibusHeptapod: new base class to run tests in Omnibus instances · 48a515bc0056
      Georges Racinet authored
      In that case the tests are to be run as the 'git' user, and
      depend on
      
      - availability of sudo
      - a sudoers configuration that gives the 'git' user the
        right to launch `gitlab-ctl` commands.
      
      In particular, this avoids the need to initiate the webdriver
      as root (which can be done but is yet another source of trouble).
      
      --HG--
      branch : stable
      48a515bc0056
    • Georges Racinet's avatar
      Heptapod: made Git executable available as attribute · 7a354d699944
      Georges Racinet authored
      This is from the client side, but still, depending on context,
      the proper one to use may not be on path.
      
      --HG--
      branch : stable
      7a354d699944
    • Georges Racinet's avatar
      Heptapod: factorizing run_shell in base class · 2344f5b0369a
      Georges Racinet authored
      The `execute` method has long been be the fundamental one whose
      implementation varies amongst subclasses.
      
      --HG--
      branch : stable
      2344f5b0369a