chemlab 0.0.1 → 0.1.0

data/.gitignore

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

data/.rspec

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

data/.rspec_parallel

@@ -1,5 +0,0 @@
---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

@@ -1,68 +0,0 @@
-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

@@ -1,23 +0,0 @@
-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

@@ -1,137 +0,0 @@
-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

@@ -1,201 +0,0 @@
-# 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.