Read about our upcoming Code of Conduct on this issue

  1. 28 Feb, 2021 6 commits
    • Georges Racinet's avatar
      User: adopted logic to close webdriver · 6d0c5253aacc
      Georges Racinet authored
      Even the `Heptapod` instance should not care about the `_webdriver`
      attribute, which is now an implementation detail.
      Also allows to close the webdriver immediately if there's any
      in `delete()`.
    • Georges Racinet's avatar
      User: made webdriver a property · 391820b64471
      Georges Racinet authored
      Now the creation of the webdriver and the login sequence are
      all transparently (and lazily) handled by the `User` instance.
      This is much simpler for tests, as demonstrated in the case
      of the test with the external_user fixture.
      This makes `Heptapod.get_user_webdriver` fairly trivial.
    • Georges Racinet's avatar
      User: adopted `session.login` · 341c98d15d38
      Georges Racinet authored
    • Georges Racinet's avatar
      User: adopted session.ensure_user · 6bb7ef588881
      Georges Racinet authored
      This follows up on the principle that the `session` module should
      be lower level than the `Heptapod` and `User` classes and prepares
      for future refactorings by avoiding import loops.
    • Georges Racinet's avatar
      session,Heptapod: standardisation of login sequence · 6254d1e283b2
      Georges Racinet authored
      - the webdriver is no longer created either by the `Heptapod`
        method or by the `session` module. An expected benefit is
        to avoid webdriver process leaks in case of failed logins
      - the special case of the `root` user is handled transparently by
    • Georges Racinet's avatar
      session, User: avoid ambiguity in login flow · c49a65be9f69
      Georges Racinet authored
      The `session` module should be about lower level, not
      object-oriented, primitives that don't care about
      caching of web drivers and generally maintaining state.
      The `login_as_user()` method did not fit there, because
      it called to the Heptapod object, which does exactly that.
      This was an ambiguity, that could easily lead to infinite
      loops when developping new features.
      It is a better fit on the `User` class. Actually the next
      natural move would be to make `webdriver` a property, renaming
      the current attribute to `_webdriver` as already done with
      The only caller, in `test_projects`, is updated by this.
  2. 25 Feb, 2021 1 commit
    • Georges Racinet's avatar
      configexpress: basic tests · c864f293f2a1
      Georges Racinet authored
      With all the capturing that Heptapod does, it is worth
      checking that configexpress actually works (renders client
      side through data sent with bundles).
  3. 27 Feb, 2021 1 commit
    • Georges Racinet's avatar
      Heptapod CI: appropriate tag for hg-current image · bb6839826f8a
      Georges Racinet authored
      We have stopped pushing to `hg-current:latest` in favor of
      `hg-current:default` long ago.
      Forthcoming new tests will need new dependencies (hg extensions)
      on the client side.
      Also updated comment for the fact that `hg-current:stable` now
      does exist.
  4. 25 Feb, 2021 3 commits
  5. 22 Feb, 2021 2 commits
    • Georges Racinet's avatar
      flake8 · 5acd811402d9
      Georges Racinet authored
    • Georges Racinet's avatar
      Heptapod CI inside: avoiding chromedriver from Ubuntu Snap · ca5e23226837
      Georges Racinet authored
      With the upgrade of the base Heptapod Docker image to Ubuntu 20.04
      in the wake of moving to GitLab 13.9 comes the fact that the whole
      chromium suite is now available as snaps only. No big surprise that
      the selenium tests launched from inside the Docker container don't
      work: the container is not even privileged in our setup (and it
      To work around this, we're now installing chromedriver from a PPA.
      For automated, sandboxed, testing, this is tolerable.
      A longer term move would be to re-explore the possibility to use
      the Firefox driver.
  6. 19 Feb, 2021 1 commit
    • Georges Racinet's avatar
      Heptapod: added start/end logging for backups · 1d18e6772e46
      Georges Racinet authored
      On HDK instances, the backup restoration is often really long,
      it's worthwile to know it has started and is still ongoing.
      In cases one launches the tests and comes back later, it is also
      useful to notice how long it took (time to purge repositories/ and
      run `rake dev:setup` to start afresh)
      Also, an immediate log that the restoration failed does not hurt.
  7. 18 Feb, 2021 6 commits
  8. 16 Feb, 2021 9 commits
    • Georges Racinet's avatar
      Heptapod: invalidate instance cache according to type and URL · 4104ff18e9be
      Georges Racinet authored
      With the new testing of production servers, the fixed user
      names can differ from an instance (e.g. local, for tests development)
      to another (actual production), leading to errors.
      Invalidating based on URL only would not be enough for people that
      actually work on the production mode – by testing it on a local
      instance (typically provided by the HDK).
      There already was a invalidation system for the token itself (test
      and recreate if it does not work), but not for the mere existence
      of an user in the registry.
      branch : stable
    • Georges Racinet's avatar
      Testing production servers: activated some runner tests · c7516a71cef9
      Georges Racinet authored
      With the previous change providing insulation by disabling
      shared and group runners on the project, this works right away.
      branch : stable
    • Georges Racinet's avatar
      Projects, Runner tests: disable shared and group runners · 5af24c7192bb
      Georges Racinet authored
      If regular runners are hooked to the instance being tested,
      we must make really sure that our mock runners don't enter a
      race with the regular runners.
      Sadly, there's no direct API setting for group runners (UPSTREAM)
      nor is there a way to block surrounding group runners with
      settings in a sub group, so we had to resort to using Selenium
      for this.
      It is important to not even attempt to disable group runners this
      way for personal namespaces, because the button is not present,
      leading to an error. It is also faster, because we don't even
      need a webdriver to be initialized in this case.
      branch : stable
    • Georges Racinet's avatar
      Testing production servers: new dedicated SSH key · b89866c6a137
      Georges Racinet authored
      Granted, it was lazy yet somewhat consistent to
      use the same key as for the `root` user of normal tests.
      The consequence was a major pain to remove it each time one
      switches from the normal mode to the production server mode
      and back. Of course, that really matters for developers of
      the tests and of the production server mode itself.
      branch : stable
    • Georges Racinet's avatar
      requests: fixing the connection pool for HTTPS · 780e14b76d48
      Georges Racinet authored
      The HTTPS pool must be distinct from the HTTP pool,
      presumably because this connection notion already
      includes TLS (by contrast with raw sockets).
      Amazingly, heptapod-tests had not been used over
      HTTPS since the first preflight tests of foss.h.n until now.
      branch : stable
    • Georges Racinet's avatar
      Testing production servers: nicer error if group owner not specified · 7aeafe8b27d8
      Georges Racinet authored
      This is better than an obscure unexpected `None` down the road.
      Maybe there's even a way to have pytest issue the proper `parser.error`
      call, but this will be good enough for the time being.
      branch : stable
    • Georges Racinet's avatar
      Testing production servers: defaulting to topmost group · 3162debaf0f1
      Georges Racinet authored
      This is a bit nicer for users, a reasonable default instead
      of a mandatory group id.
      branch : stable
    • Georges Racinet's avatar
      Testing production servers: group CLI option · 9796ee2d68f1
      Georges Racinet authored
      Up to now, project creations were occurring in the group
      owner personal namespace. With this change, they happen
      in the target group, if specified.
      branch : stable
    • Georges Racinet's avatar
      Group.api_retrieve(): owner_name optional argument · 54a2aeb10a91
      Georges Racinet authored
      Otherwise, all the API calls (including the initial GET) are
      done with `root`, and can't work in production server mode.
      branch : stable
  9. 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
  10. 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
  11. 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
  12. 13 Feb, 2021 2 commits
  13. 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.
  14. 27 Jan, 2021 1 commit