Read about our upcoming Code of Conduct on this issue

  1. 16 Feb, 2021 1 commit
  2. 15 Feb, 2021 5 commits
    • Georges Racinet's avatar
      Testing production instances: activated a MR test · dfdf8eae784d
      Georges Racinet authored
      This is non trivial exercise for the background jobs.
      branch : stable
    • Georges Racinet's avatar
      Testing production servers: working with SSH · c73d68dfb8ca
      Georges Racinet authored
      We've got a first test using SSH to pass.
      This required adaptation of the logic to load SSH keys.
      An important new requirement was to remove
      the key from the server at the end of the
      test session (quite contrary to what we
      want to do for speed on development instances), because
      it's just not acceptable for a key that *anyone can use*
      to stay associated to an user on a production server,
      even sandboxed (spam or worse).
      A nice side effect is that we will be actually testing the
      actual logic behind key registration (see
      for a small incident involving that).
      branch : stable
    • Georges Racinet's avatar
      User: non admin SSH key management · f613b1a6371a
      Georges Racinet authored
      For User instances that already have a token, it is now
      possible to manage SSH keys even if the root password is
      unknown to the tests.
      branch : stable
    • 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. 16 Feb, 2021 1 commit
    • Georges Racinet's avatar
      Heptapod: store user in registry if not creation · 71afa012e004
      Georges Racinet authored
      In the refactor for the users registry, we forgot to store
      the `User` instance for where expected users (only actual example
      is `test_basic`) already present in the database.
      Wasn't catched by CI because it runs on a fresh database.
      branch : stable
  4. 15 Feb, 2021 1 commit
    • Georges Racinet's avatar
      Heptapod: users registry now contains User instances · 6b153b87be71
      Georges Racinet authored
      This solves a discrepancy that has plagued the heptapod-tests
      code base for long.
      In the beginning, users where represented as simple dicts, themselves
      kept in a registry: `user` attribute of the `Heptapod` instance.
      Then, more advanced manipulation needs pushed to the creation of
      the `User` class, but the user registry wasn't updated at the time.
      The tricky part, explaining why it wasn't made right away is that
      we often start with a partial representation of the user: for instance
      not knowing its numeric id.
      Over time some of the test code has been updated to use higher-level
      methods of the `Heptapod` class, such as `get_user_webdriver()`, in
      prevision for the present move, but still, the registry values remained
      at heart just dicts, while lots of needed logic is implemented in
      the `User` class.
      Now we'll have `User` instances in the registry. That still leaves us
      with some illogical aspects, like lazy webdriver and token initialization
      indirected through the `Heptapod` class, instead of being transparent
      properties `User`. But from now on, improving on this should be incremental
      and involve identifiers easy to search in the code base.
      branch : stable
  5. 13 Feb, 2021 2 commits
  6. 30 Jan, 2021 1 commit
    • Georges Racinet's avatar
      tox: specific testenv for HDK context · 1e31ede8abc0
      Georges Racinet authored
      In the context of the Heptapod Development Kit (HDK), we use a
      wrapper launch script, which gives us the opportunity to inject
      environment variables. Notably we can:
      - use the same version as Python Heptapod components (such as
      - avoid the system defaults. A current use case is that pytest-parallel
        does not support Python 3.9 yet.
      With the `HDK_HEPTAPOD_TESTS_BASEPYTHON` environment variable,
      we can define `testenv:hdk` without local modifications to `tox.ini`.
      The default `python3` value should help in transition time, even if
      it doesn't seem likely that we'll have wrapper scripts that use the
      `hdk` testenv without providing the environment variable value.
  7. 27 Jan, 2021 1 commit
  8. 19 Jan, 2021 1 commit
  9. 10 Jan, 2021 1 commit
  10. 08 Jan, 2021 3 commits
  11. 11 Jan, 2021 1 commit
  12. 20 Dec, 2020 2 commits
    • Georges Racinet's avatar
      python-gitlab: tests for vcs_type and hg commit ids · 24b45f7436f3
      Georges Racinet authored
      The commit ids part is for heptapod#387.
      We check in particular that we didn't break python-gitlab's
      view of Git commits: the new `hg_id` and `short_hg_id` entries
      are not even there for them.
    • Georges Racinet's avatar
      Utilities to run tests with python-gitlab · 2f2562454c1c
      Georges Racinet authored
      The API handle (`gitlab.Gitlab` instance) can be retrieved on
      a `User` instance with `user.python_gitlab_client`).
      Since there are several GitLab API client libraries for Python,
      this raises the question whether we should make this
      conditional, and how to make variants if they cannot be installed
      in the same virtualenv (that's probably the case)
  13. 17 Dec, 2020 1 commit
  14. 16 Dec, 2020 1 commit
  15. 17 Dec, 2020 4 commits
    • Georges Racinet's avatar
      test_import: rewrote with the new assert_matching_changesets() · 7521c0c4c45e
      Georges Racinet authored
      It's actually a bit longer, but it's more explicit. The fact
      that I found it tedious to track for this change whether phase
      is there or not is a good example of why it's probably better.
      As with all assertions based on `LocalRepo.changeset_extracts()`
      I hope future failures will be clearer for investigation.
    • Georges Racinet's avatar
      test_push: rewrote some assertions with new changeset_extracts · 8e1eaef66e57
      Georges Racinet authored
      Not the best time to do *all* of them.
      Also spotted a use-case for `repo.node()`, much more recent than
      the test.
    • Georges Racinet's avatar
      utils.hg: higher level assert_matching_changesets helper · d586b25aa4d2
      Georges Racinet authored
      It is based on the previously introduced `changeset_extracts()`
      and has options for fields of comparison and order.
      The hope is that it will make failures appearing on tests
      easier to understand, especially to (relative) newcomers.
    • Georges Racinet's avatar
      utils.hg: high level method to extract changesets info · 8fa3f8406c79
      Georges Racinet authored
      This will be, I hope, more readable than the pervasive
      "log with `:` separated template / split" pattern
      we've been using.
      Especially, I expect failures to be more readily understandable.
      Using namedtuples for the extracts so that it's admissible in
      dicts and sets. The drawback is that we have to return the class
      as well, for litteral comparison. Each call gives a new class
      but instances of two such namedtuple classes are comparable.
  16. 14 Dec, 2020 2 commits
  17. 02 Dec, 2020 4 commits
  18. 29 Nov, 2020 1 commit
  19. 27 Nov, 2020 2 commits
  20. 26 Nov, 2020 2 commits
    • Georges Racinet's avatar
      Heptapod CI: hg-native remote jobs now expected to succeed · cbea8f0445ab
      Georges Racinet authored
      With the previously forgotten enabling by the tests of
      the Mercurial native repositories, these have passed for
      the first time while testing the Heptapod 0.17.1 release.
      Let's now require them to pass, hoping nothing too flaky
      will be there.
      At this point of development of the native mode, the inside
      tests still fail, and that's not so surprising, probably
      a real problem to fix, not only test harness.
    • 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)
  21. 24 Nov, 2020 3 commits