Skip to content

12.1.201907190430-e6934b21f82.c2efb1d43db QA Issue

⚠ CLOSED in favor of #866 (closed) ⚠

Details here: #867 (comment 193879419)

## Process

Each engineer validates and checks off each of their assigned QA task(s).

  1. Check off each Merge Request changes that you've tested successfully and note any issues you've created and check them off as they are resolved.
  2. If a problem is found:
    • Create an issue for it and add a sub bullet item under the corresponding validation checklist task. Link the issue there.
    • Add the severity label
    • Raise the problem in the discussion and tag relevant Engineering and Product managers.
  3. If a regression is found:
    • Create an issue for it
    • Add the severity label and the regression label
    • Raise the regression in the discussion and tag relevant Engineering and Product managers.

General Quality info can be found in the Quality Handbook.

Note: If you are assigned tasks outside your normal work hours, you're not expected to work overtime. Please complete the tasks as soon as possible during your normal work hours.

Deadline

QA testing on staging.gitlab.com for this issue should be completed by 2019-07-20 13:08 UTC. After this deadline has passed, the issue will be closed automatically.

If the deadline has passed, please perform your task as soon as possible anyway (during your normal work hours). It's important that the testing is performed, even if deployment has proceeded to a later stage.

Testing CE only changes

When testing changes in CE specifically, use dev.gitlab.org as it is running a nightly version of GitLab CE. If it is determined that the dev instance does not suffice, create a virtual machine to install the CE package and complete an install to perform the necessary testing. Currently we do not build CE packages to match that of the version in this QA issue. The best course of action would be to find the closest CE package from our nightly repository. packages.gitlab.com/gitlab/nightly-builds

Merge Requests tested in 12.1.201907190430-e6934b21f82.c2efb1d43db

Community contribution Community contribution

Plan ~"Plan"

Create ~"Create"

Manage ~"Manage"

Verify ~"Verify"

Release ~"Release"

Geo ~"Geo"

Package ~"Package"

Configure ~"Configure"

Monitor ~"Monitor"

Secure ~"Secure"

frontend frontend

uncategorized ~"uncategorized"

Automated QA for 12.1.201907190430-e6934b21f82.c2efb1d43db

No QA job could be found for this release!

You will need to set up a dedicated environment for 12.1.201907190430-e6934b21f82.c2efb1d43db by following the following steps:

Prepare the environments for testing the security fixes

Instructions to prepare environment
  1. In Google Cloud Console (access to this should have been granted during on-boarding), create a new VM instance (in the gitlab-internal project) from the qa-security-1cpu-3-75gb-ram-ubuntu-16-04-lts instance template for each version of GitLab.
  2. Find the .deb package to install:
    1. First find the pipeline for the 12.1.201907190430+ee.0 tag in the pipelines page.
    2. Then on the pipeline page, click the Ubuntu-16.04-staging job in the Upload:gitlab_com stage (or the Staging_upload stage for versions prior to 11.5), you will need the job ID later.
  3. Install the .deb package from the job artifact:
    1. SSH into the VM via the GCP console.
    2. Create a install-gitlab.sh script in your home folder: 
      TEMP_DEB="$(mktemp)"
GITLAB_PACKAGE="https://dev.gitlab.org/api/v4/projects/gitlab%2Fomnibus-gitlab/jobs/${JOB_ID}/artifacts/pkg/ubuntu-xenial/gitlab-ee_${GITLAB_VERSION}-ee.0_amd64.deb"
curl -H "PRIVATE-TOKEN: $DEV_TOKEN" "$GITLAB_PACKAGE" -o "$TEMP_DEB" &&
sudo dpkg -i "$TEMP_DEB"
rm -f "$TEMP_DEB"
      • $DEV_TOKEN needs to be set with a dev.gitlab.org personal access token so that the script can download the package
      • $JOB_ID needs to be set with the Ubuntu-16.04-staging job ID
      • $GITLAB_VERSION needs to be set with the version (without the -ee prefix, e.g. 11.4.10).
    3. Change the script's permission with chmod +x install-gitlab.sh.
    4. Run the script with ./install-gitlab.sh.
    5. Once GitLab installed, set the external_url in /etc/gitlab/gitlab.rb with sudo vim /etc/gitlab/gitlab.rb. You can find the VM's IP in the GCP console.
    6. Reconfigure and restart GitLab with sudo gitlab-ctl reconfigure && sudo gitlab-ctl restart.
    7. You may need to wait a few minutes after the above command finishes before the instance is actually accessible.
  4. Set the root's user password:
    1. Visit http://IP_OF_THE_GCP_VM and change root's password.
    2. Once the environments are ready, capture the information to add to the QA issue.

Automated QA

Instructions to perform automated QA

  • (Optional) If the QA Docker image doesn't exist, you will need to build it manually on your machine, e.g.

    # In gitlab-ee
› git fetch dev
› git checkout v12.1.201907190430-e6934b21f82.c2efb1d43db-ee
› cd qa
› docker build -t dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee-qa:12.1.201907190430-e6934b21f82.c2efb1d43db-ee .

  • Make sure to export the following environment variables (you can find the token under the GitLab QA - Access tokens 1Password items)

    • $QA_IMAGE the URL of the QA image
    • $QA_ENV_URL with the URL of the environment where the package has been deployed (usually https://staging.gitlab.com for the current version, and http://IP_OF_THE_GCP_VM for back-ported versions).
    • $GITLAB_USERNAME with root.
    • $GITLAB_ADMIN_USERNAME with $GITLAB_USERNAME.
    • $GITLAB_PASSWORD with the password you've set for the root user.
    • $GITLAB_ADMIN_PASSWORD with $GITLAB_PASSWORD.
    • $GITHUB_ACCESS_TOKEN with a valid GitHub API token that can access the https://github.com/gitlab-qa/test-project project
    • $DEV_USERNAME with your dev username
    • $DEV_TOKEN with a valid dev personal access token that has the read_registry scope
    › export QA_IMAGE="dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee-qa:12.1.201907190430-e6934b21f82.c2efb1d43db-ee"
› export QA_ENV_URL="<QA_ENV_URL>"
› export GITLAB_USERNAME="root"
› export GITLAB_ADMIN_USERNAME="$GITLAB_USERNAME"
› export GITLAB_PASSWORD="<GITLAB_PASSWORD>"
› export GITLAB_ADMIN_PASSWORD="$GITLAB_PASSWORD"
› export GITHUB_ACCESS_TOKEN="<GITHUB_ACCESS_TOKEN>"
› export DEV_USERNAME="<DEV_USERNAME>"
› export DEV_TOKEN="<DEV_TOKEN>"

  • Update gitlab-qa if needed

    › gem install gitlab-qa

  • Log into the dev container registry

    › docker login --username "$DEV_USERNAME" --password "$DEV_TOKEN" dev.gitlab.org:5005

  • Automated QA completed. QA can be parallelized manually (for now):

    # Tab 1: This should take approximately 4.5 minutes

› gitlab-qa Test::Instance::Any $QA_IMAGE $QA_ENV_URL -- qa/specs/features/api/ qa/specs/features/login/ qa/specs/features/merge_request/
    # Tab 2: This should take approximately 6 minutes

› gitlab-qa Test::Instance::Any $QA_IMAGE $QA_ENV_URL -- qa/specs/features/project/
    # Tab 3: This should take approximately 5 minutes

› gitlab-qa Test::Instance::Any $QA_IMAGE $QA_ENV_URL -- qa/specs/features/repository/

  • Post results as comments of this issue

  • Create Automation Triage RELEASE_MAJOR_VERSION RC# issues for all the automated QA failures (with failures logs + screenshots) and link it to this issue

Coordinate the Manual QA validation of the release

Click for details
  1. Notify the Security Engineer to verify the security fixes for the release.
    • The manner in which the security fixes are verified can be done in two ways.
      1. By the Quality Engineer executing the validation with close collaboration and guidance from the Security Engineer.
      2. By the Security Engineer executing the validation with the Quality Engineer monitoring the steps.
    • Note: When encountered with deadline and resource constraints, the work should be assigned for efficiency. Security Engineer should own verifying complex security validations while Quality Engineer is encouraged to help out with simpler validations. However it is important that the Security team signs off on the result of the validation.
  2. Ensure that all the items for validation are validated and checked off before moving forward.
  3. Hand off the release assignment.
    1. Once all the validation is completed, Quality Engineer un-assigns themselves from the release issue leaving only the Security Engineer and the Release Manager.

/cc @gl-quality

---

🤖 This issue was generated via triggered pipeline.

Edited by John Skarbek