- 03 Nov, 2020 8 commits
-
-
Georges Racinet authored
This will allow for nicer cleanups, especially for those created in tests. We're adopting the strong cleanup capability and the larger timeout in `Project.__exit__()` to mimic what the Project fixtures do, in the hope to have them simply use the new Context Managers.
-
Georges Racinet authored
We chose to pass a whole Project instance, because it's seem very unlikely we'd have a use case for passing an id (caller would have created the target Project or would use a fixture), and therefore it makes things simpler on the average for the caller.
-
Georges Racinet authored
We already had a persistent normal user and the `external_user` fixture. This one is not external.
-
Georges Racinet authored
Proper testing of Git operation will need this.
-
Georges Racinet authored
A bit cleaner this way. One day, we may reduce the duplication by introducing a proper MergeRequest object.
-
Georges Racinet authored
Amazingly, the `owner_api_request()` shortcut was all we needed for a long time, but we'll now will need to be able to pass the user explicitely.
-
Georges Racinet authored
-
Georges Racinet authored
This will help reducing the boiler plate and over long statements. Leveraging in test_import for immediate testing.
-
- 17 Nov, 2020 5 commits
-
-
Georges Racinet authored
The good thing is that we finally get back to sanity with boolean operators. This is now legit: if something and othercondition:
-
Georges Racinet authored
Notably, we're using `l` as a variable in short list comprehensions only (ambiguity with 1 is not a problem with any decent terminal font). This is just fine, E741 is a pain.
-
Georges Racinet authored
This way, we won't depend from Docker Hub rate limiting.
-
Georges Racinet authored
It's time to get rolling.
-
Georges Racinet authored
In the case where several jobs happen to run on the same Docker host, it's important to avoid that they use the same services. Otherwise, the first completion breaks the ones still running, because it shuts down the services they rely on. Of course, it's better not to have such voracious jobs in parallel, but that's a different issue.
-
- 31 Oct, 2020 1 commit
-
-
Georges Racinet authored
It's still far from being comprehensive, but it did catch something to be fixed.
-
- 29 Oct, 2020 3 commits
-
-
Both SHA and repo_type had to be corrected, being still hardcoded for Mercurial.
-
-
-
- 08 Nov, 2020 1 commit
-
-
Georges Racinet authored
Had forgotten that the logs are located in subdirectories. It would be tempting do just take the whole /var/log/gitlab directory, but then I'd be wary it could be too big. I expect the artifacts system to perform compression (IIRC it's artifacts are wrapped in a zip file). We do have some random failures in the nightly builds that I'd like to investigate. We'll see if that is enough.
-
- 18 Oct, 2020 2 commits
-
-
Georges Racinet authored
This spares us refreshing APT sources and installing tox, better for latency, bandwidth, given that the chances the base image is already available are high, and about the same as the octobus image meant for classical Mercurial extensions testing that's been replaced.
-
Georges Racinet authored
This parallels what's been done in omnibus-heptapod, except that we still allow manual triggering. The simplest case remains to make a MR for tests expected to pass on the latest testing Heptapod Docker image.
-
- 15 Oct, 2020 2 commits
-
-
Georges Racinet authored
This will give us the means to test heptapod#204, hence also omnibus-heptapod#12, since archive production will be done by HGitaly.
-
Georges Racinet authored
This provides the way to test the repository download links (which are backed by `hg archive` and `git archive`).
-
- 12 Oct, 2020 1 commit
-
-
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).
-
- 06 Oct, 2020 7 commits
-
-
Georges Racinet authored
We'll actually have the flake8 job that'll keep on being duplicated, but that's the price to pay for manual jobs on regular pushes. Also deduplicating the rules and preparing for future cross project triggering.
-
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 authored
-
Georges Racinet authored
Closes #14 As explained in issue comment, two shards seem to be a good, useful, starting point. --HG-- branch : stable
-
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
-
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 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.
-
- 05 Oct, 2020 10 commits
-
-
Georges Racinet authored
The simplest is to install tox via pip for the right Python, and it will bring the correct environment.
-
Georges Racinet authored
-
Georges Racinet authored
Even though we have the initial 3 minutes of lead time, it's a better idea to start with tests that don't shut down the Rails app almost immediately. --HG-- branch : stable
-
Georges Racinet authored
--HG-- branch : stable
-
Georges Racinet authored
In the current Docker image, the python3 version installed by the base Linux distribution is python3.5, which is ancient and has reached its end of life. Could very well not be supported by tox at any point. Let's use the python3 provided by Omnibus instead, as it is either 3.7 or 3.8 in the current Heptapod branches of Omnibus. --HG-- branch : stable
-
Georges Racinet authored
Now that we have Omnibus support, we can just treat the Docker container as any Omnibus instance. We still have some permission issues to take care of, in order not to run the full stack (including the web driver) as root. Let's just hope it won't poison permissions for the other runs, but if it does, that's not so hard to cure. In some future, we could even run all CI tests this way, but for now I think it's good to also test the Docker image from the outside. Closes #13 --HG-- branch : stable
-
Georges Racinet authored
This brings all the pieces together --HG-- branch : stable
-
Georges Racinet authored
This is perhaps a clearer way to indicate that it's not about testing heptapod-tests, and rather about using it to test Heptapod. Besides, we should have another job soon. --HG-- branch : stable
-
Georges Racinet authored
With the upcoming in-Docker tests, we'll need a bit of organization. --HG-- branch : stable
-
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
-