chemlab 0.0.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: dd40a0ffd6214eeb28234cfef9b4e735f57570cdecddf5e6a0cca422353ed5fc
+  data.tar.gz: 93efdc7b1093ab7226bf268d862bdba9c66fa2764e4165e0d70a49344d9de4ec
+SHA512:
+  metadata.gz: bc4380dc722dc70263eea4cd6720a753a98438dc60ee18f2a949e8b74532732b07d458b486601b37ce3a68ed1533ebbbf7f6725637462622caf3464cfc217292
+  data.tar.gz: 5c25a44ad165c00fa36233d5bae6c56adb55e4fb1eec8c713c51deb0e6ed4bfb6207d9e73d776c443d4cf9aae9e132baeb918819e68cea47ec42e60baa782171

data/.gitignore

@@ -0,0 +1,4 @@
+tmp/
+.ruby-version
+.ruby-gemset
+urls.yml

data/.rspec

@@ -0,0 +1,3 @@
+--color
+--format documentation
+--require spec_helper

data/.rspec_parallel

@@ -0,0 +1,5 @@
+--color
+--format documentation
+--format ParallelTests::RSpec::SummaryLogger --out tmp/spec_summary.log
+--format ParallelTests::RSpec::RuntimeLogger --out tmp/parallel_runtime_rspec.log
+--require spec_helper

data/Dockerfile

@@ -0,0 +1,68 @@
+FROM ruby:2.6-stretch
+LABEL maintainer="GitLab Quality Department <quality@gitlab.com>"
+ENV DEBIAN_FRONTEND noninteractive
+
+##
+# Add support for stretch-backports
+#
+RUN echo "deb http://ftp.debian.org/debian stretch-backports main" >> /etc/apt/sources.list
+
+##
+# Update APT sources and install some dependencies
+#
+RUN sed -i "s/httpredir.debian.org/ftp.us.debian.org/" /etc/apt/sources.list
+RUN apt-get update && apt-get install -y wget unzip xvfb lsb-release
+
+##
+# Install some packages from backports
+#
+RUN apt-get -y -t stretch-backports install git git-lfs
+
+##
+# Install Docker
+#
+RUN wget -q https://download.docker.com/linux/static/stable/x86_64/docker-17.09.0-ce.tgz && \
+    tar -zxf docker-17.09.0-ce.tgz && mv docker/docker /usr/local/bin/docker && \
+    rm docker-17.09.0-ce.tgz
+
+##
+# Install Google Chrome version with headless support
+#
+RUN curl -sS -L https://dl.google.com/linux/linux_signing_key.pub | apt-key add -
+RUN echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google.list
+RUN apt-get update -q && apt-get install -y google-chrome-stable && apt-get clean
+
+##
+# Install chromedriver to make it work with Selenium
+#
+RUN wget -q https://chromedriver.storage.googleapis.com/$(wget -q -O - https://chromedriver.storage.googleapis.com/LATEST_RELEASE)/chromedriver_linux64.zip
+RUN unzip chromedriver_linux64.zip -d /usr/local/bin
+
+##
+# Install K3d local cluster support
+#   https://github.com/rancher/k3d
+#
+RUN curl -s https://raw.githubusercontent.com/rancher/k3d/master/install.sh | TAG=v1.3.4 bash
+
+##
+# Install gcloud and kubectl CLI used in Auto DevOps test to create K8s
+# clusters
+#
+RUN export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)" && \
+    echo "deb http://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list && \
+    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - && \
+    apt-get update -y && apt-get install google-cloud-sdk kubectl -y
+
+WORKDIR /home/gitlab/qa
+COPY ./qa/Gemfile* /home/gitlab/qa/
+COPY ./config/initializers/0_inject_enterprise_edition_module.rb /home/gitlab/config/initializers/
+# Copy VERSION to ensure the COPY succeeds to copy at least one file since ee/app/models/license.rb isn't present in FOSS
+# The [b] part makes ./ee/app/models/license.r[b] a pattern that is allowed to return no files (which is the case in FOSS)
+COPY VERSION ./ee/app/models/license.r[b] /home/gitlab/ee/app/models/
+COPY ./lib/gitlab.rb /home/gitlab/lib/
+COPY ./lib/gitlab/utils.rb /home/gitlab/lib/gitlab/
+COPY ./INSTALLATION_TYPE ./VERSION /home/gitlab/
+RUN cd /home/gitlab/qa/ && bundle install --jobs=$(nproc) --retry=3 --quiet
+COPY ./qa /home/gitlab/qa
+
+ENTRYPOINT ["bin/test"]

data/Gemfile

@@ -0,0 +1,23 @@
+source 'https://rubygems.org'
+
+gem 'gitlab-qa'
+gem 'activesupport', '~> 6.0.2.2' # This should stay in sync with the root's Gemfile
+gem 'capybara', '~> 3.29.0'
+gem 'capybara-screenshot', '~> 1.0.23'
+gem 'rake', '~> 12.3.0'
+gem 'rspec', '~> 3.7'
+gem 'selenium-webdriver', '~> 3.12'
+gem 'airborne', '~> 0.2.13'
+gem 'nokogiri', '~> 1.10.9'
+gem 'rspec-retry', '~> 0.6.1'
+gem 'rspec_junit_formatter', '~> 0.4.1'
+gem 'faker', '~> 1.6', '>= 1.6.6'
+gem 'knapsack', '~> 1.17'
+gem 'parallel_tests', '~> 2.29'
+
+group :test do
+  gem 'pry-byebug', '~> 3.5.1', platform: :mri
+  gem "ruby-debug-ide", "~> 0.7.0"
+  gem "debase", "~> 0.2.4.1"
+  gem 'timecop', '~> 0.9.1'
+end

data/Gemfile.lock

@@ -0,0 +1,137 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    activesupport (6.0.2.2)
+      concurrent-ruby (~> 1.0, >= 1.0.2)
+      i18n (>= 0.7, < 2)
+      minitest (~> 5.1)
+      tzinfo (~> 1.1)
+      zeitwerk (~> 2.2)
+    addressable (2.7.0)
+      public_suffix (>= 2.0.2, < 5.0)
+    airborne (0.2.13)
+      activesupport
+      rack
+      rack-test (~> 0.6, >= 0.6.2)
+      rest-client (>= 1.7.3, < 3.0)
+      rspec (~> 3.1)
+    byebug (9.1.0)
+    capybara (3.29.0)
+      addressable
+      mini_mime (>= 0.1.3)
+      nokogiri (~> 1.8)
+      rack (>= 1.6.0)
+      rack-test (>= 0.6.3)
+      regexp_parser (~> 1.5)
+      xpath (~> 3.2)
+    capybara-screenshot (1.0.23)
+      capybara (>= 1.0, < 4)
+      launchy
+    childprocess (3.0.0)
+    coderay (1.1.2)
+    concurrent-ruby (1.1.6)
+    debase (0.2.4.1)
+      debase-ruby_core_source (>= 0.10.2)
+    debase-ruby_core_source (0.10.6)
+    diff-lcs (1.3)
+    domain_name (0.5.20170404)
+      unf (>= 0.0.5, < 1.0.0)
+    faker (1.9.3)
+      i18n (>= 0.7)
+    gitlab-qa (4.0.0)
+    http-cookie (1.0.3)
+      domain_name (~> 0.5)
+    i18n (1.8.2)
+      concurrent-ruby (~> 1.0)
+    knapsack (1.17.1)
+      rake
+    launchy (2.4.3)
+      addressable (~> 2.3)
+    method_source (0.9.0)
+    mime-types (3.1)
+      mime-types-data (~> 3.2015)
+    mime-types-data (3.2016.0521)
+    mini_mime (1.0.2)
+    mini_portile2 (2.4.0)
+    minitest (5.14.0)
+    netrc (0.11.0)
+    nokogiri (1.10.9)
+      mini_portile2 (~> 2.4.0)
+    parallel (1.17.0)
+    parallel_tests (2.29.0)
+      parallel
+    pry (0.11.3)
+      coderay (~> 1.1.0)
+      method_source (~> 0.9.0)
+    pry-byebug (3.5.1)
+      byebug (~> 9.1)
+      pry (~> 0.10)
+    public_suffix (4.0.1)
+    rack (2.0.7)
+    rack-test (0.8.3)
+      rack (>= 1.0, < 3)
+    rake (12.3.0)
+    regexp_parser (1.6.0)
+    rest-client (2.0.2)
+      http-cookie (>= 1.0.2, < 2.0)
+      mime-types (>= 1.16, < 4.0)
+      netrc (~> 0.8)
+    rspec (3.7.0)
+      rspec-core (~> 3.7.0)
+      rspec-expectations (~> 3.7.0)
+      rspec-mocks (~> 3.7.0)
+    rspec-core (3.7.1)
+      rspec-support (~> 3.7.0)
+    rspec-expectations (3.7.0)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.7.0)
+    rspec-mocks (3.7.0)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.7.0)
+    rspec-retry (0.6.1)
+      rspec-core (> 3.3)
+    rspec-support (3.7.0)
+    rspec_junit_formatter (0.4.1)
+      rspec-core (>= 2, < 4, != 2.12.0)
+    ruby-debug-ide (0.7.2)
+      rake (>= 0.8.1)
+    rubyzip (1.3.0)
+    selenium-webdriver (3.142.6)
+      childprocess (>= 0.5, < 4.0)
+      rubyzip (>= 1.2.2)
+    thread_safe (0.3.6)
+    timecop (0.9.1)
+    tzinfo (1.2.6)
+      thread_safe (~> 0.1)
+    unf (0.1.4)
+      unf_ext
+    unf_ext (0.0.7.4)
+    xpath (3.2.0)
+      nokogiri (~> 1.8)
+    zeitwerk (2.3.0)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  activesupport (~> 6.0.2.2)
+  airborne (~> 0.2.13)
+  capybara (~> 3.29.0)
+  capybara-screenshot (~> 1.0.23)
+  debase (~> 0.2.4.1)
+  faker (~> 1.6, >= 1.6.6)
+  gitlab-qa
+  knapsack (~> 1.17)
+  nokogiri (~> 1.10.9)
+  parallel_tests (~> 2.29)
+  pry-byebug (~> 3.5.1)
+  rake (~> 12.3.0)
+  rspec (~> 3.7)
+  rspec-retry (~> 0.6.1)
+  rspec_junit_formatter (~> 0.4.1)
+  ruby-debug-ide (~> 0.7.0)
+  selenium-webdriver (~> 3.12)
+  timecop (~> 0.9.1)
+
+BUNDLED WITH
+   1.17.3

data/README.md

@@ -0,0 +1,201 @@
+# GitLab QA - End-to-end tests for GitLab
+
+This directory contains [end-to-end tests](../../../doc/development/testing_guide/end_to_end/index.md)
+for GitLab. It includes the test framework and the tests themselves.
+
+The tests can be found in `qa/specs/features` (not to be confused with the unit
+tests for the test framework, which are in `spec/`).
+
+It is part of the [GitLab QA project](https://gitlab.com/gitlab-org/gitlab-qa).
+
+## What is it?
+
+GitLab QA is an end-to-end tests suite for GitLab.
+
+These are black-box and entirely click-driven end-to-end tests you can run
+against any existing instance.
+
+## How does it work?
+
+1. When we release a new version of GitLab, we build a Docker images for it.
+1. Along with GitLab Docker Images we also build and publish GitLab QA images.
+1. GitLab QA project uses these images to execute end-to-end tests.
+
+## Validating GitLab views / partials / selectors in merge requests
+
+We recently added a new CI job that is going to be triggered for every push
+event in CE and EE projects. The job is called `qa:selectors` and it will
+verify coupling between page objects implemented as a part of GitLab QA
+and corresponding views / partials / selectors in CE / EE.
+
+Whenever `qa:selectors` job fails in your merge request, you are supposed to
+fix [page objects](../doc/development/testing_guide/end_to_end/page_objects.md). You should also trigger end-to-end tests
+using `package-and-qa` manual action, to test if everything works fine.
+
+## How can I use it?
+
+You can use GitLab QA to exercise tests on any live instance! If you don't
+have an instance available you can follow the instructions below to use
+the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit).
+This is the recommended option if you would like to contribute to the tests.
+
+Note: GitLab QA uses [Selenium WebDriver](https://www.seleniumhq.org/) via
+[Cabybara](http://teamcapybara.github.io/capybara/), and by default it targets Chrome as
+the browser to use. You will need to have Chrome (or Chromium) and
+[chromedriver](https://chromedriver.chromium.org/) installed / in your `$PATH`.
+
+### Writing tests
+
+- [Writing tests from scratch tutorial](../doc/development/testing_guide/end_to_end/beginners_guide.md)
+    - [Best practices](../doc/development/testing_guide/best_practices.md)
+    - [Using page objects](../doc/development/testing_guide/end_to_end/page_objects.md)
+    - [Guidelines](../doc/development/testing_guide/index.md)
+    - [Tests with special setup for local environemnts](../doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md)
+
+### Run the end-to-end tests in a local development environment
+
+Follow the GDK instructions to [prepare](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/prepare.md)
+and [install](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/set-up-gdk.md)
+your local GitLab development environment.
+
+Once you have GDK running, switch to the `qa` directory. E.g., if you setup
+GDK to develop in the main `gitlab-ce` repo, the GitLab source code will be
+in a `gitlab` directory and so the end-to-end test code will be in `gitlab/qa`.
+
+From there you can run the tests. For example, the
+following call would login to the GDK instance and run all specs in
+`qa/specs/features`:
+
+```
+# Make sure to install the dependencies first with `bundle install`
+
+bundle exec bin/qa Test::Instance::All http://localhost:3000
+```
+
+Note: If you want to run tests requiring SSH against GDK, you
+will need to [modify your GDK setup](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/run_qa_against_gdk.md).
+
+#### Running EE tests
+
+When running EE tests you'll need to have a license available. GitLab engineers can [request a license](https://about.gitlab.com/handbook/developer-onboarding/#working-on-gitlab-ee).
+
+Once you have the license file you can export it as an environment variable and then the framework can use it. If you do so it will be installed automatically.
+
+```
+export EE_LICENSE=$(cat /path/to/gitlab_license)
+```
+
+### Running specific tests
+
+You can also supply specific tests to run as another parameter. For example, to
+run the repository-related specs, you can execute:
+
+```
+bundle exec bin/qa Test::Instance::All http://localhost:3000 -- qa/specs/features/browser_ui/3_create/repository
+```
+
+Since the arguments would be passed to `rspec`, you could use all `rspec`
+options there. For example, passing `--backtrace` and also line number:
+
+```
+bundle exec bin/qa Test::Instance::All http://localhost:3000 -- qa/specs/features/browser_ui/3_create/merge_request/create_merge_request_spec.rb:6 --backtrace
+```
+
+Note that the separator `--` is required; all subsequent options will be
+ignored by the QA framework and passed to `rspec`.
+
+### 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 bundle exec bin/qa Test::Instance::All https://gitlab.example.com
+```
+
+Some QA tests require logging in as an admin user. By default, the QA
+tests will use the the same `root` user seeded by the GDK.
+
+If you need to authenticate with different admin credentials, you can
+provide the `GITLAB_ADMIN_USERNAME` and `GITLAB_ADMIN_PASSWORD`
+environment variables:
+
+```
+GITLAB_ADMIN_USERNAME=admin GITLAB_ADMIN_PASSWORD=myadminpassword GITLAB_USERNAME=jsmith GITLAB_PASSWORD=password bundle exec bin/qa Test::Instance::All https://gitlab.example.com
+```
+
+If your user doesn't have permission to default sandbox group
+`gitlab-qa-sandbox`, you could also use another sandbox group by giving
+`GITLAB_SANDBOX_NAME`:
+
+```
+GITLAB_USERNAME=jsmith GITLAB_PASSWORD=password GITLAB_SANDBOX_NAME=jsmith-qa-sandbox bundle exec bin/qa Test::Instance::All https://gitlab.example.com
+```
+
+All [supported environment variables are here](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-environment-variables).
+
+### Sending additional cookies
+
+The environment variable `QA_COOKIES` can be set to send additional cookies
+on every request. This is necessary on gitlab.com to direct traffic to the
+canary fleet. To do this set `QA_COOKIES="gitlab_canary=true"`.
+
+To set multiple cookies, separate them with the `;` character, for example: `QA_COOKIES="cookie1=value;cookie2=value2"`
+
+
+### Building a Docker image to test
+
+Once you have made changes to the CE/EE repositories, you may want to build a
+Docker image to test locally instead of waiting for the `gitlab-ce-qa` or
+`gitlab-ee-qa` nightly builds. To do that, you can run **from the top `gitlab`
+directory** (one level up from this directory):
+
+```sh
+docker build -t gitlab/gitlab-ce-qa:nightly --file ./qa/Dockerfile ./
+```
+
+### Quarantined tests
+
+Tests can be put in quarantine by assigning `:quarantine` metadata. This means
+they will be skipped unless run with `--tag quarantine`. This can be used for
+tests that are expected to fail while a fix is in progress (similar to how
+[`skip` or `pending`](https://relishapp.com/rspec/rspec-core/v/3-8/docs/pending-and-skipped-examples)
+ can be used).
+
+```
+bundle exec bin/qa Test::Instance::All http://localhost:3000 -- --tag quarantine
+```
+
+If `quarantine` is used with other tags, tests will only be run if they have at
+least one of the tags other than `quarantine`. This is different from how RSpec
+tags usually work, where all tags are inclusive.
+
+For example, suppose one test has `:smoke` and `:quarantine` metadata, and
+another test has `:ldap` and `:quarantine` metadata. If the tests are run with
+`--tag smoke --tag quarantine`, only the first test will run. The test with
+`:ldap` will not run even though it also has `:quarantine`.
+
+### Running tests with a feature flag enabled
+
+Tests can be run with with a feature flag enabled by using the command-line
+option `--enable-feature FEATURE_FLAG`. For example, to enable the feature flag
+that enforces Gitaly request limits, you would use the command:
+
+```
+bundle exec bin/qa Test::Instance::All http://localhost:3000 --enable-feature gitaly_enforce_requests_limits
+```
+
+This will instruct the QA framework to enable the `gitaly_enforce_requests_limits`
+feature flag ([via the API](https://docs.gitlab.com/ee/api/features.html)), run
+all the tests in the `Test::Instance::All` scenario, and then disable the
+feature flag again.
+
+Note: the QA framework doesn't currently allow you to easily toggle a feature
+flag during a single test, [as you can in unit tests](https://docs.gitlab.com/ee/development/feature_flags.html#specs),
+but [that capability is planned](https://gitlab.com/gitlab-org/quality/team-tasks/issues/77).
+
+Note also that the `--` separator isn't used because `--enable-feature` is a QA
+framework option, not an `rspec` option.