- 04 Jan, 2020 1 commit
-
-
Georges Racinet authored
We have two new options: --heptapod-source-install --heptapod-repositories-root 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.
-
- 01 Jan, 2020 4 commits
-
-
Georges Racinet authored
Having the same default as the GDK will be convenient in the future.
-
Georges Racinet authored
The container name is now stored as an attribute on the Heptapod instance, and it's been a good opportunity to centralize docker calls there. Since we're not mentioning docker at all in the API, this is also a step towards running these tests on a source install of Heptapod: it wouldn't be hard to implement them with subprocess and direct filesystem manipulations.
-
Georges Racinet authored
This is done with py.test CLI options. Instead of the cumbersome scheme/host/port, we're simply adding a --heptapod-url option. There's a separate --heptapod-ssh-port
-
Georges Racinet authored
Now the server's SSH key is automatically accepted and previous keys are forgotten.
-
- 14 Dec, 2019 2 commits
-
-
Georges Racinet authored
We embed two freshly created SSH keys for these tests, and provide the necessary infrastructure to register them in Heptapod and retrieve them in the tests.
-
Georges Racinet authored
From now on, the forwarded ports of the Heptapod container will have to be on the `heptapod` host, as explained in README. The Heptapod object now has a `ssh_url` property that will serve as the base for performing hg commands over SSH.
-
- 17 Nov, 2019 1 commit
-
-
Georges Racinet authored
The advantage is that we can have several levels (currently setting to INFO, but we'll be able to tweak later on).
-
- 15 Nov, 2019 1 commit
-
-
Georges Racinet authored
It seems that the default branch becomes protected (FULL) by default in 10.3, which makes all our tests performing actual Git force pushes (not based on -f but on the push really not being fast-forwardable) break. This is a quickfix, we should have tests for various scenarios on protected branches, and they should test user feedback as well (see heptadod#122)
-
- 15 Sep, 2019 1 commit
-
-
Georges Racinet authored
we now have one webdriver per default user
-
- 10 Nov, 2019 1 commit
-
-
Georges Racinet authored
This led us to introduce a class for user namespaces (not really groups in GitLab terminology). We had to update all URL forming code paths for the fact that now Project.group is an object instead of a namespace name.
-
- 09 Nov, 2019 1 commit
-
-
Georges Racinet authored
This will save time while manually launching these tests and is a step towards full CI automation
-
- 17 Sep, 2019 1 commit
-
-
Georges Racinet authored
apart from the usual str/bytes dance in subprocesses and I/O, (we can assume that hg and docker exec outputs are essentially ASCII, can be handled by the default UTF-8 codec or that we'd write something dedicated otherwise), the notable thing is that we need inner fixture generator to become a context manager, because something in teardowns catches StopIteration too early and raises RuntimeError. This is cleaner anyway.
-
- 13 Sep, 2019 1 commit
-
-
Georges Racinet authored
This is more robust and faster. It also means that we have to test webdriver_create explicitely
-
- 10 Sep, 2019 1 commit
-
-
Georges Racinet authored
It should be the most reliable way to tear down the test projects and seems to be a bit faster.
-
- 09 Sep, 2019 2 commits
-
-
Georges Racinet authored
This avoids importing the project module, and in particular the masking niceties that can endeavour.
-
Georges Racinet authored
This is a bit simpler for callers, but the fixtures need it to become idempotent (hence skip_missing) for tests that call destroy() directly. In turn those tests (currently test_destroy only) don't need to depend on many fixtures nor to import 'project'
-
- 28 Aug, 2019 1 commit
-
-
Georges Racinet authored
This is necessary for some API calls, such as adding to project members
-
- 12 Aug, 2019 1 commit
-
-
Georges Racinet authored
We didn't support full name until now, but it's important because of the non-ASCII tests.
-
- 16 Jul, 2019 1 commit
-
-
Georges Racinet authored
With this change, a persistent unprivileged user `test_basic` is created, with its API token. The Heptapod fixture retrieves the token and starts a web session as this user, the project fixtures have it own their projects. It felt reasonible to have this generic user persist across test sessions, notably because user destruction is partly asynchronous in GitLab, because removing all objects authored by this user can be very long. We'll probably have this user own further test projects and create auxiliary, transient additional users to interact with the projects.
-
- 02 Aug, 2019 1 commit
-
-
Georges Racinet authored
The `heptapod` fixture now has a Selenium driver with a running session for the root user (previously represented by the `webdriver` fixture). Since it represents external state that persists even across test sessions, it is given the "session" scope, but only the Selenium part is actually teared down. Using this scope makes my running times go down from 1mn to a bit more than 40s. Factorized code between the two kinds of projects In adapting the tests to this, realized that now most of them don't even need direct references to the `heptapod` fixture.
-
- 03 Jul, 2019 3 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
This leverages Project.api_edit
-
Georges Racinet authored
This makes the `heptapod` fixture hold user password and private token information, something that we may want to revisit later, but that is simple enough for now. At instance creation, we generate a new private token for the root user, as it seems that the initially displayed value is not activated. Upon normal login, we retrieve the user private token, and store it in the `heptapod` fixture, along with its password. This should also enable us to stop hardcoding the root password and makes us close to be able to support tests running with regular users.
-
- 28 Jun, 2019 1 commit
-
-
Georges Racinet authored
with this it becomes much easier to perform direct HTTP request or GitLab JSON API requests on the test project. Also, this is a step towards multi-user tests, or at least tests not running as the 'root' user, although the fact that we're using the 'root' user and that it is the owner of all sessions and projects is still hardcoded a lot.
-
- 25 May, 2019 1 commit
-
-
Georges Racinet authored
In order to test that, we separate the cleanup from the destroy call so that test_project_destroy actually tests the feature, and keep the cleanup in the teardown sequence, as a protection for other tests in case of regressions.
-
- 03 Apr, 2019 1 commit
-
-
Raphaël Gomès authored
Moving tests to a tests subpackage, and their support to `tests.utils` (split from orginal commit by Georges Racinet <georges.racinet@octobus.net>)
-
- 05 Oct, 2018 2 commits
-
-
Paul Morelle authored
-
Paul Morelle authored
-
- 04 Oct, 2018 1 commit
-
-
Paul Morelle authored
-