74d6b8a211
In !14818 we added the ability to specify the example groups that should run via the `-t` (tag) option to rspec. It was assumed that the inclusion filter generated `{:core => true, :mattermost => true}` would run examples tagged :core OR :mattermost, when instead it means :core AND :mattermost. Here in order to assure at least some tests run, we specify that the :mattermost tagged examples are the only ones we care about. |
||
|---|---|---|
| .. | ||
| bin | ||
| qa | ||
| spec | ||
| .gitignore | ||
| .rspec | ||
| Dockerfile | ||
| Gemfile | ||
| Gemfile.lock | ||
| qa.rb | ||
| README.md | ||
GitLab QA - Integration tests for GitLab
This directory contains integration tests for GitLab.
It is part of the GitLab QA project.
What is it?
GitLab QA is an integration tests suite for GitLab.
These are black-box and entirely click-driven integration tests you can run against any existing instance.
How does it work?
- When we release a new version of GitLab, we build a Docker images for it.
- Along with GitLab Docker Images we also build and publish GitLab QA images.
- GitLab QA project uses these images to execute integration tests.
How can I use it?
You can use GitLab QA to exercise tests on any live instance! For example, the
following call would login to a local GDK instance and run all specs in
qa/specs/features:
bin/qa Test::Instance http://localhost:3000
Running specific tests
You can also supply specific tests to run as another parameter. For example, to test the EE license specs, you can run:
EE_LICENSE="<YOUR LICENSE KEY>" bin/qa Test::Instance http://localhost qa/ee
Overriding the authenticated user
Unless told otherwise, the QA tests will run as the default root user seeded
by the GDK.
If you need to authenticate as a different user, you can provide the
GITLAB_USERNAME and GITLAB_PASSWORD environment variables:
GITLAB_USERNAME=jsmith GITLAB_PASSWORD=password bin/qa Test::Instance https://gitlab.example.com