11.10.0-rc5 QA Issue
Process
Each engineer validates and checks off each of their assigned QA task(s).
- 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.
- 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.
- 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.
Deadline
QA testing on staging.gitlab.com for this issue should be completed by 2019-04-11 00:40 UTC. After this deadline has passed, Release Managers will proceed with the canary and production deployment.
Merge Requests tested in 11.10.0-rc5
Plan ~"Plan"
-
@fatihacet | Fix SVG icon colors in Related MRs widget ~"Plan" UX ~"backstage" ~"bug" frontend issues -
@fatihacet | Fix icon colors of related MRs widget ~"Plan" UX ~"backstage" ~"bug" frontend issues
Create ~"Create"
-
@iamphill | Added design management empty state ~"Create" ~"feature" feature flag frontend
Release ~"Release"
-
@dosuken123 | Create pipelines for merge requests only when source branch is updated Deliverable GitLab Premium PM Ready Product Vision 2018 ~"Release" ~"UX ready" backend ~"bug" ~"continuous delivery" ~"continuous integration" customer ~"devops" direction feature flag frontend internal customer ~"rebuild in GitLab" -
@dosuken123 | Prevent merge if the merge request pipeline is stale Deliverable GitLab Premium PM Ready Product Vision 2018 ~"Release" ~"UX ready" backend ~"continuous delivery" ~"continuous integration" customer ~"devops:release" direction ~"feature" ~"feature flags" frontend internal customer ~"rebuild in GitLab"
Monitor ~"Monitor"
-
@syasonik | Resolve Environments#additional_metrics TypeError, ensure unix format ~"Monitor" ~"P1" ~"S3" backend ~"backstage" ~"bug" ~"devops:monitor" feature flag frontend regression regression:11.10
Secure ~"Secure"
-
@axil | Copy and merge the existing SAST docs to a new location ~"Documentation" ~"Secure" ~"devops:secure"
uncategorized ~"uncategorized"
Automated QA for 11.10.0-rc5
No QA job could be found for this release!
You will need to set up a dedicated environment for 11.10.0-rc5 by following the following steps:
Prepare the environments for testing the security fixes
- 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 theqa-security-1cpu-3-75gb-ram-ubuntu-16-04-lts
instance template for each version of GitLab. - Find the
.deb
package to install:- First find the pipeline for the
11.10.0+rc5.ee.0
tag in the pipelines page. - Then on the pipeline page, click the
Ubuntu-16.04-staging
job in theUpload:gitlab_com
stage (or theStaging_upload
stage for versions prior to 11.5), you will need the job ID later.
- First find the pipeline for the
- Install the
.deb
package from the job artifact:- SSH into the VM via the GCP console.
- 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 adev.gitlab.org
personal access token so that the script can download the package -
$JOB_ID
needs to be set with theUbuntu-16.04-staging
job ID -
$GITLAB_VERSION
needs to be set with the version (without the-ee
prefix, e.g.11.4.10
).
-
- Change the script's permission with
chmod +x install-gitlab.sh
. - Run the script with
./install-gitlab.sh
. - Once GitLab installed, set the
external_url
in/etc/gitlab/gitlab.rb
withsudo vim /etc/gitlab/gitlab.rb
. You can find the VM's IP in the GCP console. - Reconfigure and restart GitLab with
sudo gitlab-ctl reconfigure && sudo gitlab-ctl restart
. - You may need to wait a few minutes after the above command finishes before the instance is actually accessible.
- Set the
root
's user password:- Visit http://IP_OF_THE_GCP_VM and change
root
's password. - Once the environments are ready, capture the information to add to the QA issue.
- Visit http://IP_OF_THE_GCP_VM and change
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 v11.10.0-rc5-ee › cd qa › docker build -t dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee-qa:11.10.0-rc5-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, andhttp://IP_OF_THE_GCP_VM
for back-ported versions). -
$GITLAB_USERNAME
withroot
. -
$GITLAB_ADMIN_USERNAME
with$GITLAB_USERNAME
. -
$GITLAB_PASSWORD
with the password you've set for theroot
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 yourdev
username -
$DEV_TOKEN
with a validdev
personal access token that has theread_registry
scope
› export QA_IMAGE="dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee-qa:11.10.0-rc5-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
- 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.
- By the Quality Engineer executing the validation with close collaboration and guidance from the Security Engineer.
- 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.
- The manner in which the security fixes are verified can be done in two ways.
- Ensure that all the items for validation are validated and checked off before moving forward.
- Hand off the release assignment.
- 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