Skip to main content

Self-service Automated QA Pipeline Setup

Document History
  • 04/25/2024 - Changed section 3 from "Terraform code to create Selenium Grid Server" to "Configure connection to Selenium Grid Server"
    Details

    This change was made to align better with the strategy of having a centrally hosted Selenium Grid Server hosted consistently on the "Ops" cluster as part of the reasoning outlined in Migrate existing QA repo to Ops cluster Selenium grid

Based on the need to enable existing repositories used by the QA team to run functional testing suites using Selenium, this page highlights the details and requirements needed to onboard and integrate existing repositories to run the tests suite execution in Gitlab as standalone pipelines or as part of a downstream pipeline in a more robust workflow.

Part 1. Onboard existing QA repository to run as standalone pipeline in Gitlab.​

Prerequisites:​

  1. Existing repository with Selenium codebase using Java.
  2. The repository must support passing environment variables to the maven execution and should have configured code to target different environments.
  3. Connection to the AWS dev account ops cluster
  4. Dockerfile for the image creation.
  5. Gitlab pipeline yaml file.
  6. Configure CICD variables on QA Repository.

Example use case: NCIA QA  link .​

1. Java Based Repository​

Screenshot of NCIA QA java based repo highlighting selenium usage

2. Support to passing variables, different target environments and run in a Gitlab pipeline.​

Env variables passing support:

https://gitlab.com/wwnorton/app/ncia/ncia-qa/-/blob/main/src/main/java/com/Norton/Utilities/UpdateConfigFile.java?ref_type=heads#L12

Different target environments support:

Screenshot of ncia-qa example repo highlighting how to structure config files to support QA, STG, and PROD

Running from Gitlab support.

Screenshot of ncia-qa example repo showing how to configure application properties and add gitlab

3. Configure connection to Selenium Grid Server​

Note: The below guidance should be used when creating new automated testing repos. To convert an existing QA repo, follow the guidance in the document focused on migration

Screenshot of GRID_IP variable in CD Settings

  1. Go to a QA repo where this GRID_IP CI/CD variable already exists - in this case TestmakerQA repo should have it
  2. Follow instructions to access the project's CI/CD variables by following this GitLab CI/CD variables documentation
  3. Add the GRID_IP variable to the CI/CD settings of your desired repo
  4. Change hubURL in src/main/java/com/wwnorton/TestMaker/utilities/ReadApplicationProperties.java to hubURL = "https://" + hubIpAddress + "/wd/hub";

4. Add the Dockerfile definition to create the test image.​

https://gitlab.com/wwnorton/app/ncia/ncia-qa/-/blob/main/Dockerfile?ref_type=heads

5. Create the gitlab pipeline (Use the following version).​

https://gitlab.com/wwnorton/app/ncia/ncia-qa/-/blob/cc79e5b2f120f28fb99013cd3f268d154ca52d6b/.gitlab-ci.yml

6. CI/CD variables setup for repository​

Set the following variables in the Gitlab repository:

CI/CD variables for the QA repo and where to set them

Get the values for those variables on AWS Secrets Manager on the Development account:

Getting values for the CI/CD vars from AWS secrets manager

Test the workflow execution by manually running the pipeline passing the variables required (this depends on the required variables per repository).

Navigating to NCIA QA --> Properties --> Run Pipeline to fire a manual test run

Part 2. Integrating the existing automation CICD pipeline to another Upstream Deployment pipeline.

To integrate the existing and previously configured pipeline to a deployment CD pipeline follow the next steps:

  1. On the upstream pipeline (the deployment cd .gitlab.yaml file) add the following job that will execute automatically after a MR is completed as part of the promotion to the target environment in the upstream pipeline.
automation-tests-qa:   
  stage: promote
    variables : 
    Environment: QA
  trigger:
     project: wwnorton/app/ncia/ncia-qa
     branch: main
     strategy: depend
  rules: 
    - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push" 
      changes:
        paths:
          - flux/qa/**/*
      when: delayed
      start_in: 1 minute

This will automatically trigger when the MR is merged and the values.yaml file is modified on the upstream pipeline.

Rinse and repeat for a different environment, make sure you pass the environment variables accordingly and the path to the values.yaml file is correct for the target environment you are trying to test.