gitlab-qa 2.1.0 → 2.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0a1792891cdd9b76cbc19fd4d505bdbee99bf11c06579d443d2280b24d91d062
-  data.tar.gz: 06d7f8564698ec57242200c7742821f2f157f347bb4c70c74b8ff340f5922e80
+  metadata.gz: 27bc2abc8cfebcb0ca9db1d08a42543c07c4a0c324bb247f5017bf021daf126a
+  data.tar.gz: d544281d1b8195ad55432abbc31ead297d64a864e6fd3dbe5caf97cd192e716c
 SHA512:
-  metadata.gz: be317b77cf388846911a1ca380f1d92716ac93f88095b18b21f6eef0aa5c0b9e8b31dddc8c0712b5424dcd31061b53b19219210f48d64bd5c74bbb68d05fcd90
-  data.tar.gz: 5af3675ee8ab80bc9f1c7e557bf6d7d66c0fcb48f2153d7f5add50f5e61456efe751a8e78caaba4cb665c9d4c3ab5e0fdf34c5563063c64c3a26b86e9448bf40
+  metadata.gz: 2fb60fe3f21ccfd1cfefa59e16ec373ad8dc9b9545ec13eca963f524a36cc7a6f9857734a73aea1f4cd7b224bb2402fd1835e8dde9dac44d6ec7c7763b0d244e
+  data.tar.gz: bccb952d05b6cee766989618f3fa53427db7c069b86e720ceeebd91a098219313650b0534aea1918643749bef65187116d8780155bd4f83e3f7f9edfd44ce4d4

data/.gitlab-ci.yml

@@ -3,7 +3,6 @@ services:
 
 stages:
   - check
-  - sanity
   - test
 
 variables:
@@ -36,24 +35,6 @@ check:rspec:
   tags:
     - docker
 
-.sanity: &sanity
-  stage: sanity
-  image: $TEST_IMAGE
-  only:
-    - schedules
-  tags:
-    - docker
-
-ce:version:
-  script: bin/qa Test::Sanity::Version CE
-  allow_failure: true
-  <<: *sanity
-
-ee:version:
-  script: bin/qa Test::Sanity::Version EE
-  allow_failure: true
-  <<: *sanity
-
 .test: &test
   stage: test
   image: $TEST_IMAGE
@@ -191,15 +172,3 @@ ee:kubernetes:
   <<: *test
   <<: *high-capacity
   <<: *ee-qa
-
-qa:staging:
-  script:
-    - export GITLAB_USERNAME="gitlab-qa"
-    - export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
-    - unset EE_LICENSE
-    - bin/qa Test::Instance::Staging
-  <<: *test
-  retry: 0
-  when: manual
-  except:
-    - triggers

data/README.md

@@ -5,17 +5,17 @@
 
 ## Definitions
 
-- **GitLab QA framework**: A framework that allows developer to write end-to-end
+- **GitLab QA framework**: A framework that allows developers to write end-to-end
   tests simply and efficiently.
   Located at [`gitlab-org/gitlab-ce@qa/qa/`][qa-framework].
-- **GitLab QA instance-level scenarios**: RSpec scenarios that are using
+- **GitLab QA instance-level scenarios**: RSpec scenarios that use the
   GitLab QA framework and Capybara to setup and perform individual end-to-end
   tests against a live GitLab instance.
   Located at [`gitlab-org/gitlab-ce@qa/qa/specs/features/`][instance-level-scenarios].
-- **GitLab QA orchestrator** (this project): An orchestration tool that allows to run various
-  QA test suites in a simple manner.
+- **GitLab QA orchestrator** (this project): An orchestration tool that enables 
+  running various QA test suites in a simple manner.
 - **GitLab QA orchestrated scenarios**: Scenarios where containers are started,
-  configured and that run instance-level scenarios against a live GitLab
+  configured, and execute instance-level scenarios against a running GitLab 
   instance.
   Located at [`gitlab-org/gitlab-qa@lib/gitlab/qa/scenario/test/`][orchestrated-scenarios].
 
@@ -31,6 +31,17 @@ GitLab consists of multiple pieces configured and packaged by
 The purpose of the QA end-to-end test suite is to verify that all pieces
 integrate well together.
 
+### Testing changes in merge requests before the merge
+
+The ultimate goal is to make it possible to run the QA test suite for any
+merge request, even before merging code into the `master` branch.
+
+### We can run tests against any instance of GitLab
+
+GitLab QA is a click-driven, black-box testing tool. We also use it to run
+tests against the staging environment, and we strive to make it useful for our 
+users as well.
+
 ### GitLab QA tests running in the CI/CD environment
 
 Manual steps should not be needed to run the QA test suite.
@@ -38,46 +49,38 @@ GitLab QA orchestrator is CI/CD environment native, which means that we should
 add new features and tests when we are comfortable with running new code in the
 CI/CD environment.
 
-### GitLab QA test failure are reproducible locally
+### GitLab QA test failures are reproducible locally
 
 Despite the fact that GitLab QA orchestrator has been built to run in the CI/CD
 environment, it is really important to make it easy for developers to reproduce
 test failures locally. It is much easier to debug things locally, than in the
-CI/CD.
+CI/CD environment.
 
 To make it easier to reproduce test failures locally we have published the
 `gitlab-qa` gem [on rubygems.org](https://rubygems.org/gems/gitlab-qa) and we
 are using exactly the same approach to run tests in the CI/CD environment.
 
-It means that using `gitlab-qa` CLI tool, that orchestrates test environment and
-runs GitLab QA test suite, is a reproducible way of running tests locally and
-in the CI/CD.
+It means that using the `gitlab-qa` CLI tool, which orchestrates the test 
+environment and runs the GitLab QA test suite, is a reproducible way of running 
+tests locally and in the CI/CD environment.
 
-It also means that we cannot have a custom code in `.gitlab-ci.yml` to, for
+It also means that we cannot have custom code in `.gitlab-ci.yml` to, for
 example, start new containers / services.
 
-### Test installation / deployment process too
+### Test the installation / deployment process too
 
-We distribute GitLab in a package (like Debian package or a Docker image) so
-we want to test installation process to ensure that our package is not broken.
+We distribute GitLab in a package (like a Debian package or a Docker image) so
+we want to test the installation process to ensure that our package is not 
+broken.
 
 But we are also working on making GitLab be a cloud native product. This means
-that using Helm becomes yet another installation / deployment process that we
-want to test with GitLab QA.
+that, for example, using Helm becomes yet another installation / deployment 
+process that we want to test with GitLab QA.
 
-Keeping in mind that we want to test our Kubernetes deployments is especially
-important with consideration of the need of testing changes in merge requests.
-
-### Testing changes in merge requests before the merge
-
-The ultimate goal is to make it possible to run the QA test suite for any
-merge request, even before merging code into the `master` branch.
-
-### We can run tests against any instance of GitLab
-
-GitLab QA is a click-driven, black-box testing tool. We also use it to run
-tests against the staging, and we strive for making it useful for our users
-as well.
+Considering our goal of being able to test all changes in merge requests, it is
+especially important to be able to test our Kubernetes deployments, as that is
+essential to scaling our test environments to efficiently handle a large number 
+of tests.
 
 ## Documentation
 
@@ -85,15 +88,19 @@ All the documentation can be found under [`docs/`](/docs/README.md).
 
 ## How do we use it
 
-Currently we trigger test suite against GitLab Docker images created by Omnibus
-nightly.
+Currently, we execute the test suite against GitLab Docker images created by 
+Omnibus nightly via a pipeline in the [nightly](https://gitlab.com/gitlab-org/quality/nightly) 
+project.
+
+We also execute the test suite nightly against our [staging environment](https://staging.gitlab.com)
+via a pipeline in the [staging project](https://gitlab.com/gitlab-org/quality/staging).
 
-We also trigger GitLab QA pipelines whenever someone clicks `package-and-qa` manual
+Finally, we trigger GitLab QA pipelines whenever someone clicks `package-and-qa` manual
 action in a merge request.
 
 ## How can you use it
 
-GitLab QA tool is published as a [Ruby Gem](https://rubygems.org/gems/gitlab-qa).
+The GitLab QA tool is published as a [Ruby Gem](https://rubygems.org/gems/gitlab-qa).
 
 You can install it with `gem install gitlab-qa`. It will expose a `gitlab-qa`
 command in your system.
@@ -107,10 +114,11 @@ All the scenarios you can run are described in the
 
 ### How to add new scenarios
 
-Scenarios (test cases) and scripts to run them are located in
+Scenarios (test cases) and scripts to run them are located in the
 [CE](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa) and
 [EE](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/qa)
-repositories under `qa/` directory, so please also check the documentation there.
+repositories under the `qa/` directory, so please also check the documentation 
+there.
 
 ## Contributing
 

data/docs/what_tests_can_be_run.md

@@ -30,6 +30,8 @@ For more details on the internals, please read the
 
 * `GITLAB_USERNAME` - username to use when signing into GitLab
 * `GITLAB_PASSWORD` - password to use when signing into GitLab
+* `GITLAB_FORKER_USERNAME` - username to use for forking a project
+* `GITLAB_FORKER_PASSWORD` - password to use for forking a project
 * `GITLAB_USER_TYPE` - type of user to use when signing into GitLab: standard (default), ldap
 * `GITLAB_LDAP_USERNAME` - LDAP username to use when signing into GitLab
 * `GITLAB_LDAP_PASSWORD` - LDAP password to use when signing into GitLab

data/lib/gitlab/qa/runtime/env.rb

@@ -11,6 +11,8 @@ module Gitlab
           'GITLAB_PASSWORD' => :user_password,
           'GITLAB_LDAP_USERNAME' => :ldap_username,
           'GITLAB_LDAP_PASSWORD' => :ldap_password,
+          'GITLAB_FORKER_USERNAME' => :forker_username,
+          'GITLAB_FORKER_PASSWORD' => :forker_password,
           'GITLAB_USER_TYPE' => :user_type,
           'GITLAB_SANDBOX_NAME' => :gitlab_sandbox_name,
           'GITLAB_QA_ACCESS_TOKEN' => :qa_access_token,

data/lib/gitlab/qa/version.rb

@@ -1,5 +1,5 @@
 module Gitlab
   module QA
-    VERSION = '2.1.0'.freeze
+    VERSION = '2.2.0'.freeze
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: gitlab-qa
 version: !ruby/object:Gem::Version
-  version: 2.1.0
+  version: 2.2.0
 platform: ruby
 authors:
 - Grzegorz Bizon
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2018-07-19 00:00:00.000000000 Z
+date: 2018-08-20 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: climate_control