InfoGrab DocsInfoGrab Docs

테스트 거버넌스 팁과 트릭

요약

이 페이지에는 일상적인 품질 엔지니어링 관련 작업에서 유용하다고 판단된 여러 팁과 트릭이 나열되어 있습니다. GitLab-QA 코드베이스 작업 중에, GitLab 프로젝트의 특정 릴리즈에 대해 GitLab-QA 파이프라인을 실행하는 것이 유용한 경우가 있습니다.

개요#

이 페이지에는 일상적인 품질 엔지니어링 관련 작업에서 유용하다고 판단된 여러 팁과 트릭이 나열되어 있습니다.

특정 GitLab 릴리즈에 대해 GitLab-QA 파이프라인 실행하기#

GitLab-QA 코드베이스 작업 중에, GitLab 프로젝트의 특정 릴리즈에 대해 GitLab-QA 파이프라인을 실행하는 것이 유용한 경우가 있습니다. 이는 특정 GitLab 릴리즈에 GitLab-QA의 변경 사항을 검증하는 데 필요한 특정 코드가 포함되어 있는 경우 등의 이유일 수 있습니다. 특정 GitLab 릴리즈에 대해 GitLab-QA 파이프라인을 실행하려면, omnibus 파이프라인에서 생성 및 태깅한 GitLab 릴리즈 버전을 알아야 합니다. 이 정보는 test-on-omnibus test job의 RELEASE 변수를 관찰하거나, test-on-omnibus job에서 트리거된 Trigger:gitlab-docker job의 마지막 출력 줄에서 확인할 수 있습니다. 다음은 RELEASE 문자열의 예시입니다:

registry.gitlab.com/gitlab-org/omnibus-gitlab/gitlab-ee:41b42271ff37bf79066ef3089432ee28cfd81d8c

이 문자열을 복사하고 새 GitLab-QA 파이프라인을 생성할 때 RELEASE 변수에 복사한 문자열을 값으로 사용합니다. QA_IMAGE라는 다른 변수도 생성하고, test-on-omnibus 업스트림 job에서 확인할 수 있는 값으로 설정합니다. 다음은 QA_IMAGE 문자열의 예시입니다:

 registry.gitlab.com/gitlab-org/gitlab/gitlab-ee-qa:qa-shl-use-unique-group-for-access-termination-specs

이 문자열은 이미지 이름의 -qa 접미사와 GitLab 프로젝트의 브랜치 이름인 태그를 제외하면 RELEASE와 동일합니다.

이제 변경 사항이 있는 브랜치에 대해 파이프라인을 실행합니다.

또한 GitLab 머지 리퀘스트의 test-on-omnibus job에서 RELEASE 및 QA_IMAGE 변수를 사용하여 특정 GitLab 환경에 대한 수동 GitLab-QA 파이프라인을 트리거하는 것도 가능합니다. 예를 들어, 다음은 Staging에 대해 수동 GitLab QA 파이프라인을 실행하기 위한 링크입니다.

  • 참고: registry.gitlab.com이 사용되는 경우, 인증 오류를 방지하기 위해 GITLAB_QA_CONTAINER_REGISTRY_ACCESS_TOKEN 변수도 프로덕션 gitlab-qa 사용자의 액세스 토큰 값으로 포함해야 합니다.

특정 GitLab-QA 브랜치의 코드를 사용하여 엔드투엔드 테스트 파이프라인 실행하기#

라이브 환경에 대해 특정 GitLab-QA 브랜치에서 실행하기#

GitLab-QA 코드베이스의 변경 사항이 gitlab-org/gitlab nightly 스케줄 파이프라인, Staging, Pre-Prod, Canary 또는 Production 파이프라인에 미치는 영향을 테스트해야 하는 경우가 많습니다. 이는 이러한 프로젝트 중 하나에서 파이프라인을 수동으로 트리거하고, QA_BRANCH 변수를 GitLab-QA 프로젝트에서 작업 중인 브랜치 이름으로 설정하여 달성할 수 있습니다. 결과적으로, 파이프라인은 지정된 브랜치를 체크아웃하고 최신 배포된 gem 대신 gitlab-qa gem을 빌드합니다.

GitLab 브랜치 머지 리퀘스트에 대해 특정 GitLab-QA 브랜치에서 실행하기#

테스트 브랜치를 체크아웃하고 Gemfile을 편집하여 GitLab-QA 브랜치를 통해 gitlab-qa 라인을 설치하도록 변경할 수 있습니다.

예를 들어, qa/gemfile에서:

gem 'gitlab-qa', git: 'https://gitlab.com/gitlab-org/gitlab-qa.git', branch: ''

bundle install도 실행하고 Gemfile.lock도 커밋해야 합니다. 이렇게 하면 gitlab-qa gem이 커스텀 브랜치에서 빌드될 수 있습니다.

GitLab-QA 디버깅을 위한 VS Code 설정#

Ruby LSP VS Code 확장은 Ruby 코드를 디버깅하는 기능을 포함하여 VS Code에 몇 가지 Ruby 관련 기능을 추가합니다.

확장을 설치한 후 VS Code를 사용하여 로컬 GDK에 대해 실행되는 엔드투엔드 스펙을 디버깅할 수 있습니다. launch.json에 실행 구성을 추가해야 합니다. 예를 들어, 다음 launch.json은 사이드바의 실행 보기 목록에 Debug Test::Instance::All current file이라는 구성을 추가합니다. 그런 다음 편집기에서 스펙 파일을 열고 디버깅(F5)을 시작하면 VS Code가 스펙 파일의 테스트를 실행합니다.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Test::Instance::All current file",
      "type": "ruby_lsp",
      "request": "launch",
      "useBundler": true,
      "pathToBundler": "<path_to_bundler>",
      "cwd": "${workspaceRoot}/qa",
      "program": "${workspaceRoot}/qa/bin/qa",
      "env": {
        "CHROME_HEADLESS": "false",
        "QA_LOG_LEVEL": "debug"
      },
      "args": [
          "Test::Instance::All",
          "http://localhost:3000",
          "--",
          "${file}"
      ]
    }
  ]
}

여러 구성을 포함할 수 있으며, 환경 변수나 커맨드라인 옵션을 포함할 수 있습니다. 예를 들어, 다음은 Staging에서 스모크 테스트를 디버깅하는 구성입니다:

{
  "name": "Debug Staging Smoke tests",
  "type": "Ruby",
  "request": "launch",
  "useBundler": true,
  "pathToBundler": "<path_to_bundler>",
  "cwd": "${workspaceRoot}/qa",
  "program": "${workspaceRoot}/qa/bin/qa",
  "env": {
    "CHROME_HEADLESS": "false",
    "QA_LOG_LEVEL": "debug",
    "GITLAB_USERNAME": "gitlab-qa",
    "GITLAB_PASSWORD": "from 1Password",
    "GITLAB_QA_ACCESS_TOKEN": "from 1Password"
  },
  "args": [
      "Test::Instance::All",
      "https://staging.gitlab.com",
      "--",
      "--tag", "smoke"
  ]
}

실험적 자동 확장 러너 설정#

때로는 다양한 머신 유형을 시험하고 비교하기 위해 자동 확장 러너를 배포하는 것이 유용합니다.

이를 위해 다음 단계를 따릅니다:

gitlab-qa-resources GCP 프로젝트에서 공유 캐시에 접근하기 위한 서비스 계정을 생성합니다.

서비스 계정 자격 증명 JSON 파일을 다운로드합니다.

gitlab-qa-resources GCP 프로젝트에서 자동 확장 러너 관리자를 호스팅할 VM 인스턴스를 생성합니다.

VM 인스턴스에 서비스 계정을 추가합니다.

  • VM 인스턴스에 SSH 키를 추가합니다.

  • 서비스 계정 자격 증명 JSON 파일을 VM 인스턴스에 업로드합니다 (예: scp ~/Downloads/gitlab-qa-resources-abc123.json <your-username>@VM-IP:/home/<your-username>).

gitlab-qa-resources GCP 프로젝트에서 공유 캐시용 스토리지 버킷을 생성합니다.

VM 인스턴스에 SSH로 접속합니다 (GCP의 웹 인터페이스 사용).

자동 확장 러너 관리자 설치 단계를 따릅니다:

gitlab-runner 설치.

러너에 특정 태그를 설정해야 합니다.

  • 러너 executor로 docker+machine을 설정합니다.

  • 서비스 계정 자격 증명 JSON 파일을 최종 목적지로 이동합니다 (sudo 사용): sudo mv home/<your-username>/gitlab-qa-resources-abc123.json /etc/gitlab-runner/service-account.json

  • 다음과 같은 구성으로 러너 관리자를 편집합니다 ([runners.machine] 문서를 반드시 확인하세요):

concurrent = 500
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "n2d-highcpu-4 Relevant description of the runner manager"
  url = "https://gitlab.com/"
  token = "[REDACTED]"
  executor = "docker+machine"
  limit = 500
  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
  request_concurrency = 500
  environment = [
    "DOCKER_TLS_CERTDIR=",
    "DOCKER_DRIVER=overlay2",
    "FF_USE_DIRECT_DOWNLOAD=true",
    "FF_GITLAB_REGISTRY_HELPER_IMAGE=true"
  ]

  [runners.custom_build_dir]
    enabled = true

  [runners.cache]
    Type = "gcs"
    Shared = true
    [runners.cache.gcs]
      BucketName = "BUCKET-NAME-FOR-THE-SHARED-CACHE"
      CredentialsFile = "/etc/gitlab-runner/service-account.json"

  [runners.docker]
    tls_verify = false
    image = "ruby:2.7"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    shm_size = 0
    volumes = [
      "/cache",
      "/certs/client"
    ]

  [runners.machine]
    IdleCount = 0
    IdleTime = 600
    MachineDriver = "google"
    MachineName = "rymai-n2d-hc-4-%s"
    MachineOptions = [
      # Additional machine options can be added using the Google Compute Engine driver.
      # If you experience problems with an unreachable host (ex. "Waiting for SSH"),
      # you should remove optional parameters to help with debugging.
      # https://docs.docker.com/machine/drivers/gce/
      "google-project=gitlab-qa-resources",
      "google-zone=us-central1-a", # e.g. 'us-central1-a', full list in https://cloud.google.com/compute/docs/regions-zones/
      "google-machine-type=n2d-highcpu-4", # e.g. 'n1-standard-8'
      "google-disk-size=50",
      "google-disk-type=pd-ssd",
      "google-label=gl_resource_type:ci_ephemeral",
      "google-username=cos",
      "google-operation-backoff-initial-interval=2",
      "google-use-internal-ip",
      "engine-registry-mirror=https://mirror.gcr.io",
    ]
    OffPeakTimezone = ""
    OffPeakIdleCount = 0
    OffPeakIdleTime = 0
    MaxBuilds = 20

    [[runners.machine.autoscaling]]
      Periods = ["* * 8-18 * * mon-fri *"] # During the weekends
      IdleCount = 0
      IdleTime = 600
      Timezone = "UTC"

작업 자동화를 위한 스크립트와 도구#

툴박스#

Quality Toolbox에는 GitLab 엔드투엔드 테스트 작업 시 유용한 여러 스크립트가 포함되어 있습니다. 예를 들어 플레이키 테스트 보고서를 생성하거나 job 성공률을 보고하는 스크립트가 있습니다.

Rake 작업#

qa/tools 디렉터리에는 스케줄에 따라 자동화된 작업을 수행하는 Rake 작업(예: 테스트 실행 후 하위 그룹 삭제)이나 필요에 따라 실행할 수 있는 작업(예: 개인 액세스 토큰 취소)이 포함되어 있습니다.

테스트 SSH 키 삭제#

이 스크립트는 특정 사용자의 SSH 키를 삭제합니다. qa 디렉터리의 delete_test_ssh_keys Rake 작업을 통해 실행할 수 있습니다.

Rake 작업은 삭제할 키를 제한하고 드라이 런을 수행하는 데 사용할 수 있는 세 가지 인수를 허용합니다.

  • 첫 번째 인수인 title_portion은 제공된 문자열을 포함하는 키만 삭제하도록 제한합니다.

  • 두 번째 인수인 delete_before는 주어진 날짜 이전에 생성된 키만 삭제하도록 제한합니다.

  • 세 번째 선택적 인수인 dry_run은 명령이 드라이 런으로 실행될지 여부를 결정하며, 삭제될 키를 요약합니다. 드라이 런으로 실행하려면 true로 설정합니다.

두 개의 환경 변수도 필요합니다:

  • GITLAB_ADDRESS는 타깃 GitLab 인스턴스의 주소입니다.

  • GITLAB_QA_ACCESS_TOKEN은 API 접근 권한이 있는 개인 액세스 토큰이어야 하며, 키가 삭제될 사용자의 토큰이어야 합니다.

예를 들어, 다음 명령은 제공된 개인 액세스 토큰을 가진 사용자에 대해 https://staging.gitlab.com에서 E2E test key:가 포함된 제목의 SSH 키 중 2020-08-02 이전에 생성된 모든 키를 삭제합니다:

GITLAB_QA_ACCESS_TOKEN=secret GITLAB_ADDRESS=https://staging.gitlab.com bundle exec rake "delete_test_ssh_keys[E2E test key:, 2020-08-02]"

기본 패스워드 설정 및 개인 액세스 토큰 생성#

아직 설정되지 않은 경우 기본 패스워드(Runtime::User.default_password에서)를 설정하고 개인 액세스 토큰을 생성하는 Rake 작업이 있습니다.

이는 새로운 GitLab 인스턴스(예: omnibus-GitLab Docker 이미지)에서 테스트할 때 로그인하여 수동으로 액세스 토큰을 생성하지 않으려는 경우에 유용합니다.

사용 예시(gitlab/qa 디렉터리에서 실행):

$ bundle exec rake  'initialize_gitlab_auth[https://gitlab.test]'
Signing in and creating the default password for the root user if it's not set already...
Creating an API scoped access token for the root user...
Token: <some_token_value>

테스트 거버넌스 팁과 트릭

GitLab v19.1
원문 보기
요약

이 페이지에는 일상적인 품질 엔지니어링 관련 작업에서 유용하다고 판단된 여러 팁과 트릭이 나열되어 있습니다. GitLab-QA 코드베이스 작업 중에, GitLab 프로젝트의 특정 릴리즈에 대해 GitLab-QA 파이프라인을 실행하는 것이 유용한 경우가 있습니다.

개요#

이 페이지에는 일상적인 품질 엔지니어링 관련 작업에서 유용하다고 판단된 여러 팁과 트릭이 나열되어 있습니다.

특정 GitLab 릴리즈에 대해 GitLab-QA 파이프라인 실행하기#

GitLab-QA 코드베이스 작업 중에, GitLab 프로젝트의 특정 릴리즈에 대해 GitLab-QA 파이프라인을 실행하는 것이 유용한 경우가 있습니다. 이는 특정 GitLab 릴리즈에 GitLab-QA의 변경 사항을 검증하는 데 필요한 특정 코드가 포함되어 있는 경우 등의 이유일 수 있습니다. 특정 GitLab 릴리즈에 대해 GitLab-QA 파이프라인을 실행하려면, omnibus 파이프라인에서 생성 및 태깅한 GitLab 릴리즈 버전을 알아야 합니다. 이 정보는 test-on-omnibus test job의 RELEASE 변수를 관찰하거나, test-on-omnibus job에서 트리거된 Trigger:gitlab-docker job의 마지막 출력 줄에서 확인할 수 있습니다. 다음은 RELEASE 문자열의 예시입니다:

registry.gitlab.com/gitlab-org/omnibus-gitlab/gitlab-ee:41b42271ff37bf79066ef3089432ee28cfd81d8c

이 문자열을 복사하고 새 GitLab-QA 파이프라인을 생성할 때 RELEASE 변수에 복사한 문자열을 값으로 사용합니다. QA_IMAGE라는 다른 변수도 생성하고, test-on-omnibus 업스트림 job에서 확인할 수 있는 값으로 설정합니다. 다음은 QA_IMAGE 문자열의 예시입니다:

 registry.gitlab.com/gitlab-org/gitlab/gitlab-ee-qa:qa-shl-use-unique-group-for-access-termination-specs

이 문자열은 이미지 이름의 -qa 접미사와 GitLab 프로젝트의 브랜치 이름인 태그를 제외하면 RELEASE와 동일합니다.

이제 변경 사항이 있는 브랜치에 대해 파이프라인을 실행합니다.

또한 GitLab 머지 리퀘스트의 test-on-omnibus job에서 RELEASE 및 QA_IMAGE 변수를 사용하여 특정 GitLab 환경에 대한 수동 GitLab-QA 파이프라인을 트리거하는 것도 가능합니다. 예를 들어, 다음은 Staging에 대해 수동 GitLab QA 파이프라인을 실행하기 위한 링크입니다.

  • 참고: registry.gitlab.com이 사용되는 경우, 인증 오류를 방지하기 위해 GITLAB_QA_CONTAINER_REGISTRY_ACCESS_TOKEN 변수도 프로덕션 gitlab-qa 사용자의 액세스 토큰 값으로 포함해야 합니다.

특정 GitLab-QA 브랜치의 코드를 사용하여 엔드투엔드 테스트 파이프라인 실행하기#

라이브 환경에 대해 특정 GitLab-QA 브랜치에서 실행하기#

GitLab-QA 코드베이스의 변경 사항이 gitlab-org/gitlab nightly 스케줄 파이프라인, Staging, Pre-Prod, Canary 또는 Production 파이프라인에 미치는 영향을 테스트해야 하는 경우가 많습니다. 이는 이러한 프로젝트 중 하나에서 파이프라인을 수동으로 트리거하고, QA_BRANCH 변수를 GitLab-QA 프로젝트에서 작업 중인 브랜치 이름으로 설정하여 달성할 수 있습니다. 결과적으로, 파이프라인은 지정된 브랜치를 체크아웃하고 최신 배포된 gem 대신 gitlab-qa gem을 빌드합니다.

GitLab 브랜치 머지 리퀘스트에 대해 특정 GitLab-QA 브랜치에서 실행하기#

테스트 브랜치를 체크아웃하고 Gemfile을 편집하여 GitLab-QA 브랜치를 통해 gitlab-qa 라인을 설치하도록 변경할 수 있습니다.

예를 들어, qa/gemfile에서:

gem 'gitlab-qa', git: 'https://gitlab.com/gitlab-org/gitlab-qa.git', branch: ''

bundle install도 실행하고 Gemfile.lock도 커밋해야 합니다. 이렇게 하면 gitlab-qa gem이 커스텀 브랜치에서 빌드될 수 있습니다.

GitLab-QA 디버깅을 위한 VS Code 설정#

Ruby LSP VS Code 확장은 Ruby 코드를 디버깅하는 기능을 포함하여 VS Code에 몇 가지 Ruby 관련 기능을 추가합니다.

확장을 설치한 후 VS Code를 사용하여 로컬 GDK에 대해 실행되는 엔드투엔드 스펙을 디버깅할 수 있습니다. launch.json에 실행 구성을 추가해야 합니다. 예를 들어, 다음 launch.json은 사이드바의 실행 보기 목록에 Debug Test::Instance::All current file이라는 구성을 추가합니다. 그런 다음 편집기에서 스펙 파일을 열고 디버깅(F5)을 시작하면 VS Code가 스펙 파일의 테스트를 실행합니다.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Test::Instance::All current file",
      "type": "ruby_lsp",
      "request": "launch",
      "useBundler": true,
      "pathToBundler": "<path_to_bundler>",
      "cwd": "${workspaceRoot}/qa",
      "program": "${workspaceRoot}/qa/bin/qa",
      "env": {
        "CHROME_HEADLESS": "false",
        "QA_LOG_LEVEL": "debug"
      },
      "args": [
          "Test::Instance::All",
          "http://localhost:3000",
          "--",
          "${file}"
      ]
    }
  ]
}

여러 구성을 포함할 수 있으며, 환경 변수나 커맨드라인 옵션을 포함할 수 있습니다. 예를 들어, 다음은 Staging에서 스모크 테스트를 디버깅하는 구성입니다:

{
  "name": "Debug Staging Smoke tests",
  "type": "Ruby",
  "request": "launch",
  "useBundler": true,
  "pathToBundler": "<path_to_bundler>",
  "cwd": "${workspaceRoot}/qa",
  "program": "${workspaceRoot}/qa/bin/qa",
  "env": {
    "CHROME_HEADLESS": "false",
    "QA_LOG_LEVEL": "debug",
    "GITLAB_USERNAME": "gitlab-qa",
    "GITLAB_PASSWORD": "from 1Password",
    "GITLAB_QA_ACCESS_TOKEN": "from 1Password"
  },
  "args": [
      "Test::Instance::All",
      "https://staging.gitlab.com",
      "--",
      "--tag", "smoke"
  ]
}

실험적 자동 확장 러너 설정#

때로는 다양한 머신 유형을 시험하고 비교하기 위해 자동 확장 러너를 배포하는 것이 유용합니다.

이를 위해 다음 단계를 따릅니다:

gitlab-qa-resources GCP 프로젝트에서 공유 캐시에 접근하기 위한 서비스 계정을 생성합니다.

서비스 계정 자격 증명 JSON 파일을 다운로드합니다.

gitlab-qa-resources GCP 프로젝트에서 자동 확장 러너 관리자를 호스팅할 VM 인스턴스를 생성합니다.

VM 인스턴스에 서비스 계정을 추가합니다.

  • VM 인스턴스에 SSH 키를 추가합니다.

  • 서비스 계정 자격 증명 JSON 파일을 VM 인스턴스에 업로드합니다 (예: scp ~/Downloads/gitlab-qa-resources-abc123.json <your-username>@VM-IP:/home/<your-username>).

gitlab-qa-resources GCP 프로젝트에서 공유 캐시용 스토리지 버킷을 생성합니다.

VM 인스턴스에 SSH로 접속합니다 (GCP의 웹 인터페이스 사용).

자동 확장 러너 관리자 설치 단계를 따릅니다:

gitlab-runner 설치.

러너에 특정 태그를 설정해야 합니다.

  • 러너 executor로 docker+machine을 설정합니다.

  • 서비스 계정 자격 증명 JSON 파일을 최종 목적지로 이동합니다 (sudo 사용): sudo mv home/<your-username>/gitlab-qa-resources-abc123.json /etc/gitlab-runner/service-account.json

  • 다음과 같은 구성으로 러너 관리자를 편집합니다 ([runners.machine] 문서를 반드시 확인하세요):

concurrent = 500
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "n2d-highcpu-4 Relevant description of the runner manager"
  url = "https://gitlab.com/"
  token = "[REDACTED]"
  executor = "docker+machine"
  limit = 500
  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
  request_concurrency = 500
  environment = [
    "DOCKER_TLS_CERTDIR=",
    "DOCKER_DRIVER=overlay2",
    "FF_USE_DIRECT_DOWNLOAD=true",
    "FF_GITLAB_REGISTRY_HELPER_IMAGE=true"
  ]

  [runners.custom_build_dir]
    enabled = true

  [runners.cache]
    Type = "gcs"
    Shared = true
    [runners.cache.gcs]
      BucketName = "BUCKET-NAME-FOR-THE-SHARED-CACHE"
      CredentialsFile = "/etc/gitlab-runner/service-account.json"

  [runners.docker]
    tls_verify = false
    image = "ruby:2.7"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    shm_size = 0
    volumes = [
      "/cache",
      "/certs/client"
    ]

  [runners.machine]
    IdleCount = 0
    IdleTime = 600
    MachineDriver = "google"
    MachineName = "rymai-n2d-hc-4-%s"
    MachineOptions = [
      # Additional machine options can be added using the Google Compute Engine driver.
      # If you experience problems with an unreachable host (ex. "Waiting for SSH"),
      # you should remove optional parameters to help with debugging.
      # https://docs.docker.com/machine/drivers/gce/
      "google-project=gitlab-qa-resources",
      "google-zone=us-central1-a", # e.g. 'us-central1-a', full list in https://cloud.google.com/compute/docs/regions-zones/
      "google-machine-type=n2d-highcpu-4", # e.g. 'n1-standard-8'
      "google-disk-size=50",
      "google-disk-type=pd-ssd",
      "google-label=gl_resource_type:ci_ephemeral",
      "google-username=cos",
      "google-operation-backoff-initial-interval=2",
      "google-use-internal-ip",
      "engine-registry-mirror=https://mirror.gcr.io",
    ]
    OffPeakTimezone = ""
    OffPeakIdleCount = 0
    OffPeakIdleTime = 0
    MaxBuilds = 20

    [[runners.machine.autoscaling]]
      Periods = ["* * 8-18 * * mon-fri *"] # During the weekends
      IdleCount = 0
      IdleTime = 600
      Timezone = "UTC"

작업 자동화를 위한 스크립트와 도구#

툴박스#

Quality Toolbox에는 GitLab 엔드투엔드 테스트 작업 시 유용한 여러 스크립트가 포함되어 있습니다. 예를 들어 플레이키 테스트 보고서를 생성하거나 job 성공률을 보고하는 스크립트가 있습니다.

Rake 작업#

qa/tools 디렉터리에는 스케줄에 따라 자동화된 작업을 수행하는 Rake 작업(예: 테스트 실행 후 하위 그룹 삭제)이나 필요에 따라 실행할 수 있는 작업(예: 개인 액세스 토큰 취소)이 포함되어 있습니다.

테스트 SSH 키 삭제#

이 스크립트는 특정 사용자의 SSH 키를 삭제합니다. qa 디렉터리의 delete_test_ssh_keys Rake 작업을 통해 실행할 수 있습니다.

Rake 작업은 삭제할 키를 제한하고 드라이 런을 수행하는 데 사용할 수 있는 세 가지 인수를 허용합니다.

  • 첫 번째 인수인 title_portion은 제공된 문자열을 포함하는 키만 삭제하도록 제한합니다.

  • 두 번째 인수인 delete_before는 주어진 날짜 이전에 생성된 키만 삭제하도록 제한합니다.

  • 세 번째 선택적 인수인 dry_run은 명령이 드라이 런으로 실행될지 여부를 결정하며, 삭제될 키를 요약합니다. 드라이 런으로 실행하려면 true로 설정합니다.

두 개의 환경 변수도 필요합니다:

  • GITLAB_ADDRESS는 타깃 GitLab 인스턴스의 주소입니다.

  • GITLAB_QA_ACCESS_TOKEN은 API 접근 권한이 있는 개인 액세스 토큰이어야 하며, 키가 삭제될 사용자의 토큰이어야 합니다.

예를 들어, 다음 명령은 제공된 개인 액세스 토큰을 가진 사용자에 대해 https://staging.gitlab.com에서 E2E test key:가 포함된 제목의 SSH 키 중 2020-08-02 이전에 생성된 모든 키를 삭제합니다:

GITLAB_QA_ACCESS_TOKEN=secret GITLAB_ADDRESS=https://staging.gitlab.com bundle exec rake "delete_test_ssh_keys[E2E test key:, 2020-08-02]"

기본 패스워드 설정 및 개인 액세스 토큰 생성#

아직 설정되지 않은 경우 기본 패스워드(Runtime::User.default_password에서)를 설정하고 개인 액세스 토큰을 생성하는 Rake 작업이 있습니다.

이는 새로운 GitLab 인스턴스(예: omnibus-GitLab Docker 이미지)에서 테스트할 때 로그인하여 수동으로 액세스 토큰을 생성하지 않으려는 경우에 유용합니다.

사용 예시(gitlab/qa 디렉터리에서 실행):

$ bundle exec rake  'initialize_gitlab_auth[https://gitlab.test]'
Signing in and creating the default password for the root user if it's not set already...
Creating an API scoped access token for the root user...
Token: <some_token_value>