Read about our upcoming Code of Conduct on this issue

  1. 16 Feb, 2021 3 commits
  2. 15 Feb, 2021 2 commits
    • Georges Racinet's avatar
      Testing production servers: first test without root · ef0f9ec9f942
      Georges Racinet authored
      We introduce a new "Group owner" CLI option to specify the
      relevant user, with the idea in mind that all test data will
      evntually be created inside this group. For now it is
      in the user personal namespace for simplicity.
      The basic idea is to avoid changing the test itself,
      playing on the fixtures. The first test to actually
      work in this mode is the very simple `push_basic` test.
      Of course some tests perform more server-side object
      creation, assuming admin powers, and would need deeper
      adaptation, but a good majority of our tests should work
      To achieve this, we subclass `Heptapod` and replace preparation
      (of the `root` and `test_basic` users) with preparation of the
      given Group owner.
      branch : stable
    • Georges Racinet's avatar
      Testing production servers: created option, test selection system · 368dfe7d4fd2
      Georges Racinet authored
      Only those tests that have the `@suitable.prod_server` mark will
      be run in this mode.
      Currently validated with the `push_basic` test.
      branch : stable
  3. 27 Nov, 2020 1 commit
  4. 24 Nov, 2020 1 commit
  5. 03 Nov, 2020 2 commits
  6. 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
      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).
  7. 06 Oct, 2020 3 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.
    • 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`.
    • 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.
  8. 05 Oct, 2020 1 commit
  9. 20 Jul, 2020 1 commit
  10. 03 Jun, 2020 3 commits
    • Georges Racinet's avatar
      Reduced logging noise from concurrency control code · 115128936034
      Georges Racinet authored
      Keeping logs about tests claiming thread monopoly at the INFO
      level, but ordinary tests signaling can be pushed down to DEBUG.
    • Georges Racinet's avatar
      Running the tests for GDK installations · 554378d00e82
      Georges Racinet authored
      The `--heptapod-gdk` option declares the test to be launched
      in GDK context, leading to the new `GdkHeptapod` class to be
      instantiated, with the GDK root dir specified with `--heptapod-gdk-root`.
      The new `` decorator will allow to declare tests that need
      services (and rake) management, hence will be satisfied more broadly than
      the `docker` marker. Notably these tests won't be skipped in GDK context.
    • Georges Racinet's avatar
      conftest: reorder boolean variables · fff421a1f0ee
      Georges Racinet authored
      Just for readability
  11. 12 May, 2020 1 commit
  12. 27 Apr, 2020 2 commits
  13. 04 Apr, 2020 1 commit
    • Georges Racinet's avatar
      Hashed or not variants for tests of project transfers and destruction · 10fa8ba48883
      Georges Racinet authored
      Like the other ones, these are Docker only, since we don't have
      a real service manager in the source (GDK) case. And that's why they
      are additions to the existing test: we still want the basic form
      of the test to be executed in the source case.
      All of this is terribly inefficient, and it would also be better
      to minimize the number of restarts by grouping hashed and legacy
      storage tests together.
  14. 01 Apr, 2020 1 commit
  15. 31 Mar, 2020 2 commits
    • Georges Racinet's avatar
      Concurrency: using the proper fixtures everywhere · bbc38784a062
      Georges Racinet authored
      Most tests will just inherit that from `test_project` or
      `public_project`. For the others, it has to be explicit.
    • Georges Racinet's avatar
      New fixtures to control concurrency · 958411521890
      Georges Racinet authored
      We currently have some tests that cannot be changed to support
      concurrency and that will break all concurrent running tests.
      These two new fixtures provide a solution to that, by preventing
      concurrency while these are running.
      The idea is that `breaks_concurrent` tests will wait for any
      concurrent test to finish, and then prevent any other
      test to run while they are runnning.
      All other tests have to use the `accepts_concurrent` fixture
  16. 27 Mar, 2020 1 commit
  17. 13 Mar, 2020 1 commit
    • Georges Racinet's avatar
      Ability to run the tests in concurrent (multithreaded) mode · 4a3f75099b04
      Georges Racinet authored
      Since 14a569275d1c, the name of projects used in fixtures are
      unique, hence it's in theory possible to run the tests in parallel.
      In practice, as of this writing, some of our tests are flaky when
      run concurrently.
      We should not run the tests with several processes, because each will
      want to set the GitLab user tokens independently in the `heptapod`
      session scoped fixture. However, in multithreaded mode, we can
      guarantee that the `heptapod` fixture gets set up exactly once.
      Besides being faster, this is interesting to exert Heptapod on the current
      GitLab 12, by upping the chances of race conditions, notably in the
      asynchronous handling of post-receives.
  18. 20 Feb, 2020 1 commit
  19. 19 Feb, 2020 3 commits
    • Georges Racinet's avatar
      Making tests independent of surrounding HGRCs · dd6348d0688b
      Georges Racinet authored
      In order to be really reproducible, this is needed,
      and long overdue
    • Georges Racinet's avatar
      Making project names single usage · 14a569275d1c
      Georges Racinet authored
      The various problems with teardown of projects, that can't always
      be fixed remotely, have been a pain for a long time.
      They are worse in constrained environments, as in CI contexts and
      are always a pain point while bumping upstream GitLab versions,
      because we always have to pay the price to make project deletion
      work first.
      By doing this, we lose the ability to easily find the current test
      project in logs etc, but it's comparatively acceptable
    • Georges Racinet's avatar
      Supporting running through a Selenium RemoteWebDriver · 90fc419eedf0
      Georges Racinet authored
      This is a preliminary for any CI attempt, since installing the webdriver
      inside a Docker container is a long and error prone process.
      This will allow to use a separate service image such as
      `selenium/standalone-chrome` and that may also turn to be a good option
      even outside Docker-based CI contexts.
      The new `Heptapod.new_webdriver()` method is now the unique one to be
      called to create new drivers, a preliminary to be able to run the
      tests with other drivers anyway. In particular, this should come handy
      if installing chromedriver is a problem.
  20. 15 Feb, 2020 1 commit
    • Georges Racinet's avatar
      Declarative system for network connections from Heptapod · b92b9db84c8b
      Georges Racinet authored
      We'll need to have Heptapod initiate connections to the
      system running the tests, in order to test outbound operations
      such as web hooks.
      We introduce a marker for tests that rely on this, so that they
      can be skipped, together with the new `--heptapod-reverse-call-host`
      option, for that to be possible, with reasonable defaults.
  21. 19 Jan, 2020 3 commits
    • Georges Racinet's avatar
      New `heptapod-ssh-user` option · 155961c2b15c
      Georges Racinet authored
      This will be useful for testing on remote servers, since we
      can't know it in advance.
      We could probably request the API for that
      but we aren't at this point (and it would slow the tests down a bit).
      The default value is 'git', though.
    • Georges Racinet's avatar
      Support for tests on remote servers · 5f890c68b50c
      Georges Racinet authored
      This is controlled by the new `--heptapod-remote` option.
      It has the effect of skipping all tests marked with
      This works by instantiation of the base `Heptapod` class for
      the `heptapod` fixture
    • Georges Racinet's avatar
      Helpers to mark tests as needing filesystem access · 883562126281
      Georges Racinet authored
      This uses the mark system of pytest, and will be
      leveraged for conditional skipping in a later move
  22. 04 Jan, 2020 1 commit
    • Georges Racinet's avatar
      Supporting Heptapod source installs · 6b9f58423048
      Georges Racinet authored
      We have two new options:
      In source installs, as provided by the GitLab Development Kit
      (GDK), we obviously don't have docker commands, but we have
      direct access to processes and filesystem paths.
      To support that, we move the Heptapod class to its own
      module, and split it in a base class with two subclasses.
      We also introduce higher level file manipulation, using the
      tar file uploads as before in the Docker case, and direct
      file manipulation in the source case. We drop the artificial
      flexibility we had about uid/gid: they aren't usable in the
      source case, and they are fixed in the Docker case anyway.
      Also, the SSH url have to be different, because it's the current
      user in the source case.
  23. 01 Jan, 2020 4 commits