3.8. Pipeline을 코드로 사용


Pipeline을 코드로 사용하면 클러스터 관리자 및 필요한 권한이 있는 사용자는 소스 코드 Git 리포지토리의 일부로 파이프라인 템플릿을 정의할 수 있습니다. 소스 코드 푸시 또는 구성된 Git 리포지토리의 가져오기 요청에 의해 트리거되면 해당 기능은 파이프라인을 실행하고 상태를 보고합니다.

3.8.1. 주요 기능

코드 파이프라인은 다음 기능을 지원합니다.

  • Git 리포지토리를 호스팅하는 플랫폼에서 요청 상태 및 제어를 가져옵니다.
  • GitHub Checks API에서 재확인을 포함하여 파이프라인 실행 상태를 설정합니다.
  • GitHub 가져오기 요청 및 커밋 이벤트
  • /retest 와 같은 주석에서 요청 작업을 가져옵니다.
  • Git 이벤트가 필터링되고 각 이벤트마다 별도의 파이프라인이 있습니다.
  • 로컬 작업, Tekton Hub 및 원격 URL을 포함하여 Pipeline의 자동 작업 확인.
  • GitHub Blob 및 오브젝트 API를 사용하여 구성을 검색합니다.
  • GitHub 조직의 ACL(액세스 목록) 또는 Prow 스타일 OWNER 파일을 사용합니다.
  • 부트스트랩 및 Pipeline을 코드 리포지토리로 관리하기 위한 tkn pac CLI 플러그인.
  • GitHub 앱, GitHub Webhook, Bitbucket Server 및 Bitbucket Cloud에 대한 지원

3.8.2. OpenShift Container Platform에 코드로 Pipeline 설치

Red Hat OpenShift Pipelines Operator를 설치할 때 openshift-pipelines 네임스페이스에 Code로 Pipeline이 설치됩니다. 자세한 내용은 추가 리소스 섹션에 OpenShift Pipelines 설치 섹션을 참조하십시오.

Operator를 사용하여 Code로 Pipeline의 기본 설치를 비활성화하려면 TektonConfig 사용자 정의 리소스에서 enable 매개변수의 값을 false 로 설정합니다.

...
 spec:
    platforms:
      openshift:
        pipelinesAsCode:
          enable: false
          settings:
            application-name: Pipelines as Code CI
            auto-configure-new-github-repo: "false"
            bitbucket-cloud-check-source-ip: "true"
            hub-catalog-name: tekton
            hub-url: https://api.hub.tekton.dev/v1
            remote-tasks: "true"
            secret-auto-create: "true"
...

선택적으로 다음 명령을 실행할 수 있습니다.

$ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": false}}}}}'

Red Hat OpenShift Pipelines Operator를 사용하여 Code로 Pipeline의 기본 설치를 활성화하려면 TektonConfig 사용자 정의 리소스에서 enable 매개변수 값을 true 로 설정합니다.

...
 spec:
    platforms:
      openshift:
        pipelinesAsCode:
          enable: true
          settings:
            application-name: Pipelines as Code CI
            auto-configure-new-github-repo: "false"
            bitbucket-cloud-check-source-ip: "true"
            hub-catalog-name: tekton
            hub-url: https://api.hub.tekton.dev/v1
            remote-tasks: "true"
            secret-auto-create: "true"
...

선택적으로 다음 명령을 실행할 수 있습니다.

$ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": true}}}}}'

3.8.3. 코드 CLI로 Pipeline 설치

클러스터 관리자는 로컬 머신의 tkn pacopc CLI 툴을 사용하거나 테스트를 위한 컨테이너로 사용할 수 있습니다. Red Hat OpenShift Pipelines용 tkn CLI를 설치할 때 tkn pacopc CLI 도구가 자동으로 설치됩니다.

지원되는 플랫폼에 대해 tkn pacopc 버전 1.9.1 바이너리를 설치할 수 있습니다.

3.8.4. Git 리포지토리 호스팅 서비스 공급자와 함께 파이프라인을 코드로 사용

Pipeline을 코드로 설치한 후 클러스터 관리자는 Git 리포지토리 호스팅 서비스 공급자를 구성할 수 있습니다. 현재 다음 서비스가 지원됩니다.

  • GitHub App
  • GitHub Webhook
  • GitLab
  • Bitbucket Server
  • Bitbucket Cloud
참고

GitHub App은 파이프라인과 함께 코드로 사용하는 데 권장되는 서비스입니다.

3.8.5. GitHub App에서 파이프라인을 코드로 사용

GitHub Apps는 Red Hat OpenShift Pipelines와의 통합 지점 역할을 하며 Git 기반 워크플로를 OpenShift Pipelines에 활용합니다. 클러스터 관리자는 모든 클러스터 사용자에 대해 단일 GitHub App을 구성할 수 있습니다. GitHub 앱이 Pipeline을 Code로 사용하려면 GitHub 앱의 Webhook가 GitHub 이벤트를 수신 대기하는 Code 이벤트 리스너 경로(또는 Ingress 끝점)로 Pipeline을 가리키는지 확인하십시오.

3.8.5.1. GitHub 앱 구성

클러스터 관리자는 다음 명령을 실행하여 GitHub App을 생성할 수 있습니다.

$ tkn pac bootstrap github-app

tkn pac CLI 플러그인이 설치되지 않은 경우 GitHub App을 수동으로 생성할 수 있습니다.

절차

Pipeline용 GitHub App을 코드로 수동으로 생성하고 구성하려면 다음 단계를 수행합니다.

  1. GitHub 계정에 로그인합니다.
  2. Settings Developer settings GitHub Apps 로 이동하여 새 GitHub 앱을 클릭합니다.
  3. GitHub 앱 양식에 다음 정보를 제공합니다.

    • GitHub Application Name:OpenShift Pipelines
    • 홈페이지 URL: OpenShift 콘솔 URL
    • Webhook URL: 파이프라인을 코드 경로 또는 수신 URL로 설정합니다. echo https://$(oc get route -n openshift-pipelines pipelines-as-code-controller -o jsonpath='{.spec.host}') 명령을 실행하여 찾을 수 있습니다.
    • Webhook 보안: 임의의 시크릿. openssl rand -hex 20 명령을 실행하여 시크릿을 생성할 수 있습니다.
  4. 다음 리포지토리 권한을 선택합니다.

    • Check:읽기 & 쓰기
    • 내용:읽기 & 쓰기
    • 문제:읽기 & 쓰기
    • metadata:읽기 전용
    • 가져오기 요청:읽기 & 쓰기
  5. 다음 조직 권한을 선택합니다.

    • 멤버:읽기 전용
    • 계획:읽기 전용
  6. 다음 사용자 권한 선택:

    • Check run
    • 문제 코멘트
    • pull request
    • push
  7. Create GitHub App 을 클릭합니다.
  8. 새로 만든 GitHub 앱의 세부 정보 페이지에서 맨 위에 표시된 앱 ID 를 확인합니다.
  9. 개인 키 섹션에서 개인 키 생성을 클릭하여 GitHub 앱의 개인 키를 자동으로 생성하고 다운로드합니다. 향후 참조 및 사용을 위해 개인 키를 안전하게 저장합니다.
  10. Pipeline과 함께 사용할 리포지토리에 생성된 앱을 코드로 설치합니다.

3.8.5.2. GitHub 앱에 액세스하도록 Pipeline을 코드로 구성

새로 생성된 GitHub 앱에 액세스하도록 Pipeline을 코드로 구성하려면 다음 명령을 실행합니다.

$ oc -n openshift-pipelines create secret generic pipelines-as-code-secret \
        --from-literal github-private-key="$(cat <PATH_PRIVATE_KEY>)" \ 1
        --from-literal github-application-id="<APP_ID>" \ 2
        --from-literal webhook.secret="<WEBHOOK_SECRET>" 3
1
GitHub App을 구성하는 동안 다운로드한 개인 키의 경로입니다.
2
GitHub 앱의 앱 ID 입니다.
3
GitHub 앱을 만들 때 제공되는 Webhook 보안입니다.
참고

코드의 파이프라인은 GitHub Enterprise에서 설정된 헤더를 탐지하고 GitHub Enterprise API 권한 부여 URL에 사용하여 GitHub Enterprise에서 자동으로 작동합니다.

3.8.5.3. 관리자 관점에서 GitHub 앱 생성

클러스터 관리자는 Pipeline을 코드로 사용하도록 OpenShift Container Platform 클러스터를 사용하여 GitHub App을 구성할 수 있습니다. 이 구성을 사용하면 빌드 배포에 필요한 작업 세트를 실행할 수 있습니다.

사전 요구 사항

Operator Hub에서 Red Hat OpenShift Pipelines pipelines-1.9 Operator를 설치했습니다.

절차

  1. 관리자 화면에서 탐색 창을 사용하여 파이프라인 으로 이동합니다.
  2. Pipelines 페이지에서 Setup GitHub App 을 클릭합니다.
  3. GitHub 앱 이름을 입력합니다. 예: pipelines-ci-clustername-testui.
  4. 설정 을 클릭합니다.
  5. 브라우저에 메시지가 표시되면 Git 암호를 입력합니다.
  6. Create GitHub App for <username >을 클릭합니다. 여기서 < username >은 GitHub 사용자 이름입니다.

검증

GitHub 앱이 성공적으로 생성되면 OpenShift Container Platform 웹 콘솔이 열리고 애플리케이션에 대한 세부 정보가 표시됩니다.

GitHub 앱 세부 정보

GitHub 앱의 세부 정보는 openShift-pipelines 네임스페이스에 시크릿으로 저장됩니다.

GitHub 애플리케이션과 관련된 name, link, secret과 같은 세부 정보를 보려면 Pipeline 으로 이동한 후 View GitHub App 을 클릭합니다.

3.8.6. GitHub Webhook에서 코드로 Pipeline 사용

GitHub 앱을 만들 수 없는 경우 리포지토리에서 GitHub Webhook를 사용하여 파이프라인을 코드로 사용합니다. 그러나 GitHub Webhook에서 Code로 Pipeline을 사용하면 GitHub Check Runs API에 액세스할 수 없습니다. 작업의 상태는 가져오기 요청에 대한 주석으로 추가되며 확인 탭에서 사용할 수 없습니다.

참고

GitHub Webhook를 사용한 Code인 파이프라인은 /retest/ok-to-test 와 같은 GitOps 주석을 지원하지 않습니다. 연속 통합(CI)을 다시 시작하려면 리포지토리에 대한 새 커밋을 생성합니다. 예를 들어 변경 없이 새 커밋을 생성하려면 다음 명령을 사용할 수 있습니다.

$ git --amend -a --no-edit && git push --force-with-lease <origin> <branchname>

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.
  • 인증을 위해 GitHub에서 개인 액세스 토큰을 생성합니다.

    • 안전하고 세분화된 토큰을 생성하려면 범위를 특정 리포지토리로 제한하고 다음 권한을 부여합니다.

      표 3.7. 세분화된 토큰에 대한 권한
      이름액세스

      관리

      읽기 전용

      메타데이터

      읽기 전용

      콘텐츠

      읽기 전용

      커밋 상태

      읽기 및 쓰기

      pull request

      읽기 및 쓰기

      Webhook

      읽기 및 쓰기

    • 클래식 토큰을 사용하려면 범위를 공개 리포지토리의 public_ repo 및 프라이빗 리포지토리에 대한 리포지토리로 설정합니다. 또한 짧은 토큰 만료 기간을 제공하고 토큰을 대체 위치에 기록하십시오.

      참고

      tkn pac CLI를 사용하여 Webhook를 구성하려면 admin:repo_hook 범위를 추가합니다.

절차

  1. Webhook를 구성하고 Repository CR(사용자 정의 리소스)을 생성합니다.

    • tkn pac CLI 툴을 사용하여 Webhook를 구성하고 Repository CR을 자동으로 생성하려면 다음 명령을 사용합니다.

      $ tkn pac create repo

      대화형 출력 샘플

      ? Enter the Git repository url (default: https://github.com/owner/repo):
      ? Please enter the namespace where the pipeline should run (default: repo-pipelines):
      ! Namespace repo-pipelines is not found
      ? Would you like me to create the namespace repo-pipelines? Yes
      ✓ Repository owner-repo has been created in repo-pipelines namespace
      ✓ Setting up GitHub Webhook for Repository https://github.com/owner/repo
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: sJNwdmTifHTs):  sJNwdmTifHTs
      ℹ ️You now need to create a GitHub personal access token, please checkout the docs at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token for the required scopes
      ? Please enter the GitHub access token:  ****************************************
      ✓ Webhook has been created on repository owner/repo
      🔑 Webhook Secret owner-repo has been created in the repo-pipelines namespace.
      🔑 Repository CR owner-repo has been updated with webhook secret in the repo-pipelines namespace
      ℹ Directory .tekton has been created.
      ✓ We have detected your repository using the programming language Go.
      ✓ A basic template has been created in /home/Go/src/github.com/owner/repo/.tekton/pipelinerun.yaml, feel free to customize it.

    • 웹 후크를 구성하고 수동으로 Repository CR을 생성하려면 다음 단계를 수행합니다.

      1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다.

        $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
      2. GitHub 리포지토리 또는 조직에서 다음 단계를 수행합니다.

        1. Settings > Webhooks 로 이동하여 Webhook 추가 를 클릭합니다.
        2. Payload URL 을 코드 컨트롤러 공용 URL로 Pipeline에 설정합니다.
        3. 콘텐츠 유형을 application/json 으로 선택합니다.
        4. 웹 후크 시크릿을 추가하고 대체 위치에 기록해 둡니다. openssl 이 로컬 시스템에 설치되어 있으면 임의의 시크릿을 생성합니다.

          $ openssl rand -hex 20
        5. Let me select individual events and select these events: Commit 댓글,Issue comments ,Pull request, Pushes 를 선택합니다.
        6. Webhook 추가를 클릭합니다.
      3. OpenShift 클러스터에서 개인 액세스 토큰 및 웹 후크 시크릿을 사용하여 Secret 오브젝트를 생성합니다.

        $ oc -n target-namespace create secret generic github-webhook-config \
          --from-literal provider.token="<GITHUB_PERSONAL_ACCESS_TOKEN>" \
          --from-literal webhook.secret="<WEBHOOK_SECRET>"
      4. 리포지토리 CR을 생성합니다.

        예: 리포지토리 CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
        kind: Repository
        metadata:
          name: my-repo
          namespace: target-namespace
        spec:
          url: "https://github.com/owner/repo"
          git_provider:
            secret:
              name: "github-webhook-config"
              key: "provider.token" # Set this if you have a different key in your secret
            webhook_secret:
              name: "github-webhook-config"
              key: "webhook.secret" # Set this if you have a different key for your secret

        참고

        Code로 파이프라인은 OpenShift Secret 오브젝트 및 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.

  2. 선택 사항: 기존 리포지토리 CR의 경우 여러 GitHub Webhook 보안을 추가하거나 삭제된 보안을 대신 제공합니다.

    1. tkn pac CLI 툴을 사용하여 Webhook를 추가합니다.

      예: tkn pac CLI를 사용한 추가 Webhook

      $ tkn pac webhook add -n repo-pipelines

      대화형 출력 샘플

      ✓ Setting up GitHub Webhook for Repository https://github.com/owner/repo
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: AeHdHTJVfAeH):  AeHdHTJVfAeH
      ✓ Webhook has been created on repository owner/repo
      🔑 Secret owner-repo has been updated with webhook secert in the repo-pipelines namespace.

    2. 기존 OpenShift Secret 오브젝트에서 webhook.secret 키를 업데이트합니다.
  3. 선택 사항: 기존 리포지토리 CR의 경우 개인 액세스 토큰을 업데이트합니다.

    • tkn pac CLI 툴을 사용하여 개인 액세스 토큰을 업데이트합니다.

      예: tkn pac CLI를 사용하여 개인 액세스 토큰 업데이트

      $ tkn pac webhook update-token -n repo-pipelines

      대화형 출력 샘플

      ? Please enter your personal access token:  ****************************************
      🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

    • 또는 Repository CR을 수정하여 개인 액세스 토큰을 업데이트합니다.

      1. 리포지토리 CR에서 시크릿 이름을 찾습니다.

        ...
        spec:
          git_provider:
            secret:
              name: "github-webhook-config"
        ...
      2. oc patch 명령을 사용하여 $target_namespace 네임스페이스에서 $NEW_TOKEN 값을 업데이트합니다.

        $ oc -n $target_namespace patch secret github-webhook-config -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

3.8.7. GitLab에서 코드로 파이프라인 사용

조직 또는 프로젝트에서 GitLab을 기본 플랫폼으로 사용하는 경우 GitLab에서 Webhook와 함께 파이프라인을 리포지토리의 코드로 사용할 수 있습니다.

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.
  • 인증을 위해 GitLab의 프로젝트 또는 조직 관리자로 개인 액세스 토큰을 생성합니다.

    참고
    • tkn pac CLI를 사용하여 Webhook를 구성하려면 admin:repo_hook 범위를 토큰에 추가합니다.
    • 특정 프로젝트에 대해 토큰 범위를 사용하면 분기된 리포지토리에서 전송된MR(분산 요청)에 API 액세스 권한을 제공할 수 없습니다. 이러한 경우 Code로 파이프라인은 MR에 대한 주석으로 파이프라인의 결과를 표시합니다.

절차

  1. Webhook를 구성하고 Repository CR(사용자 정의 리소스)을 생성합니다.

    • tkn pac CLI 툴을 사용하여 Webhook를 구성하고 Repository CR을 자동으로 생성하려면 다음 명령을 사용합니다.

      $ tkn pac create repo

      대화형 출력 샘플

      ? Enter the Git repository url (default: https://gitlab.com/owner/repo):
      ? Please enter the namespace where the pipeline should run (default: repo-pipelines):
      ! Namespace repo-pipelines is not found
      ? Would you like me to create the namespace repo-pipelines? Yes
      ✓ Repository repositories-project has been created in repo-pipelines namespace
      ✓ Setting up GitLab Webhook for Repository https://gitlab.com/owner/repo
      ? Please enter the project ID for the repository you want to be configured,
        project ID refers to an unique ID (e.g. 34405323) shown at the top of your GitLab project : 17103
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: lFjHIEcaGFlF):  lFjHIEcaGFlF
      ℹ ️You now need to create a GitLab personal access token with `api` scope
      ℹ ️Go to this URL to generate one https://gitlab.com/-/profile/personal_access_tokens, see https://is.gd/rOEo9B for documentation
      ? Please enter the GitLab access token:  **************************
      ? Please enter your GitLab API URL::  https://gitlab.com
      ✓ Webhook has been created on your repository
      🔑 Webhook Secret repositories-project has been created in the repo-pipelines namespace.
      🔑 Repository CR repositories-project has been updated with webhook secret in the repo-pipelines namespace
      ℹ Directory .tekton has been created.
      ✓ A basic template has been created in /home/Go/src/gitlab.com/repositories/project/.tekton/pipelinerun.yaml, feel free to customize it.

    • 웹 후크를 구성하고 수동으로 Repository CR을 생성하려면 다음 단계를 수행합니다.

      1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다.

        $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
      2. GitLab 프로젝트에서 다음 단계를 수행합니다.

        1. 왼쪽 사이드바를 사용하여 Settings > Webhooks 로 이동합니다.
        2. URL 을 코드 컨트롤러 공용 URL로 파이프라인에 설정합니다.
        3. 웹 후크 시크릿을 추가하고 대체 위치에 기록해 둡니다. openssl 이 로컬 시스템에 설치되어 있으면 임의의 시크릿을 생성합니다.

          $ openssl rand -hex 20
        4. Let me select individual events and select these events: Commit 댓글,Issue comments ,Pull request, Pushes 를 선택합니다.
        5. 변경 사항 저장을 클릭합니다.
      3. OpenShift 클러스터에서 개인 액세스 토큰 및 웹 후크 시크릿을 사용하여 Secret 오브젝트를 생성합니다.

        $ oc -n target-namespace create secret generic gitlab-webhook-config \
          --from-literal provider.token="<GITLAB_PERSONAL_ACCESS_TOKEN>" \
          --from-literal webhook.secret="<WEBHOOK_SECRET>"
      4. 리포지토리 CR을 생성합니다.

        예: 리포지토리 CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
        kind: Repository
        metadata:
          name: my-repo
          namespace: target-namespace
        spec:
          url: "https://gitlab.com/owner/repo" 1
          git_provider:
            secret:
              name: "gitlab-webhook-config"
              key: "provider.token" # Set this if you have a different key in your secret
            webhook_secret:
              name: "gitlab-webhook-config"
              key: "webhook.secret" # Set this if you have a different key for your secret

        1
        현재 코드로는 GitLab에 대한 개인 인스턴스를 자동으로 탐지하지 않습니다. 이 경우 git_provider.url 사양 아래에 API URL을 지정합니다. 일반적으로 git_provider.url 사양을 사용하여 API URL을 수동으로 덮어쓸 수 있습니다.
    참고
    • Code로 파이프라인은 OpenShift Secret 오브젝트 및 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.
  2. 선택 사항: 기존 리포지토리 CR의 경우 여러 GitLab Webhook 보안을 추가하거나 삭제된 보안을 대신 제공합니다.

    1. tkn pac CLI 툴을 사용하여 Webhook를 추가합니다.

      예: tkn pac CLI를 사용하여 추가 Webhook 추가

      $ tkn pac webhook add -n repo-pipelines

      대화형 출력 샘플

      ✓ Setting up GitLab Webhook for Repository https://gitlab.com/owner/repo
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: AeHdHTJVfAeH):  AeHdHTJVfAeH
      ✓ Webhook has been created on repository owner/repo
      🔑 Secret owner-repo has been updated with webhook secert in the repo-pipelines namespace.

    2. 기존 OpenShift Secret 오브젝트에서 webhook.secret 키를 업데이트합니다.
  3. 선택 사항: 기존 리포지토리 CR의 경우 개인 액세스 토큰을 업데이트합니다.

    • tkn pac CLI 툴을 사용하여 개인 액세스 토큰을 업데이트합니다.

      예: tkn pac CLI를 사용하여 개인 액세스 토큰 업데이트

      $ tkn pac webhook update-token -n repo-pipelines

      대화형 출력 샘플

      ? Please enter your personal access token:  ****************************************
      🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

    • 또는 Repository CR을 수정하여 개인 액세스 토큰을 업데이트합니다.

      1. 리포지토리 CR에서 시크릿 이름을 찾습니다.

        ...
        spec:
          git_provider:
            secret:
              name: "gitlab-webhook-config"
        ...
      2. oc patch 명령을 사용하여 $target_namespace 네임스페이스에서 $NEW_TOKEN 값을 업데이트합니다.

        $ oc -n $target_namespace patch secret gitlab-webhook-config -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

3.8.8. Bitbucket Cloud에서 코드로 Pipeline 사용

조직 또는 프로젝트에서 Bitbucket Cloud를 기본 플랫폼으로 사용하는 경우 Bitbucket Cloud에서 Webhook와 함께 리포지토리에 대한 코드로 Pipeline을 사용할 수 있습니다.

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.
  • Bitbucket Cloud에서 앱 암호를 만듭니다.

    • 다음 확인란을 선택하여 토큰에 적절한 권한을 추가합니다.

      • 계정: 이메일,읽기
      • 작업 공간 멤버십: 읽기,쓰기
      • 프로젝트: 읽기,쓰기
      • 문제: 읽기,쓰기
      • pull requests: Read,Write

        참고
        • tkn pac CLI를 사용하여 Webhook를 구성하려면 토큰에 Webhooks:ReadWrite 권한을 추가합니다.
        • 생성된 암호 또는 토큰 사본을 대체 위치에 저장합니다.

절차

  1. Webhook를 구성하고 Repository CR을 생성합니다.

    • tkn pac CLI 툴을 사용하여 Webhook를 구성하고 Repository CR을 자동으로 생성하려면 다음 명령을 사용합니다.

      $ tkn pac create repo

      대화형 출력 샘플

      ? Enter the Git repository url (default: https://bitbucket.org/workspace/repo):
      ? Please enter the namespace where the pipeline should run (default: repo-pipelines):
      ! Namespace repo-pipelines is not found
      ? Would you like me to create the namespace repo-pipelines? Yes
      ✓ Repository workspace-repo has been created in repo-pipelines namespace
      ✓ Setting up Bitbucket Webhook for Repository https://bitbucket.org/workspace/repo
      ? Please enter your bitbucket cloud username:  <username>
      ℹ ️You now need to create a Bitbucket Cloud app password, please checkout the docs at https://is.gd/fqMHiJ for the required permissions
      ? Please enter the Bitbucket Cloud app password:  ************************************
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ✓ Webhook has been created on repository workspace/repo
      🔑 Webhook Secret workspace-repo has been created in the repo-pipelines namespace.
      🔑 Repository CR workspace-repo has been updated with webhook secret in the repo-pipelines namespace
      ℹ Directory .tekton has been created.
      ✓ A basic template has been created in /home/Go/src/bitbucket/repo/.tekton/pipelinerun.yaml, feel free to customize it.

    • 웹 후크를 구성하고 수동으로 Repository CR을 생성하려면 다음 단계를 수행합니다.

      1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다.

        $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
      2. Bitbucket Cloud에서 다음 단계를 수행합니다.

        1. Bitbucket Cloud 리포지토리의 왼쪽 탐색 창을 사용하여 Repository settings > Webhooks 로 이동하고 Webhook 추가 를 클릭합니다.
        2. 제목을 설정합니다. 예를 들면 "Pipelines as Code"입니다.
        3. URL 을 코드 컨트롤러 공용 URL로 파이프라인에 설정합니다.
        4. 다음 이벤트를 선택합니다. 리포지토리: 내보내기 요청,Pull Request: Created,Pull Request: Updated, Pull Request: Comment created.
        5. 저장을 클릭합니다.
      3. OpenShift 클러스터에서 대상 네임스페이스에 app 암호를 사용하여 Secret 오브젝트를 생성합니다.

        $ oc -n target-namespace create secret generic bitbucket-cloud-token \
          --from-literal provider.token="<BITBUCKET_APP_PASSWORD>"
      4. 리포지토리 CR을 생성합니다.

        예: 리포지토리 CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
        kind: Repository
        metadata:
          name: my-repo
          namespace: target-namespace
        spec:
          url: "https://bitbucket.com/workspace/repo"
          branch: "main"
          git_provider:
            user: "<BITBUCKET_USERNAME>" 1
            secret:
              name: "bitbucket-cloud-token" 2
              key: "provider.token" # Set this if you have a different key in your secret

        1
        소유자 파일에서 ACCOUNT_ID 만 사용자를 참조할 수 있습니다.
        2
        코드 파이프라인은 git_provider.secret 사양에서 참조하는 시크릿과 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.
    참고
    • Bitbucket Cloud에서는 tkn pac create 및 tkn pac 부트스트랩 명령이 지원되지 않습니다.
    • Bitbucket Cloud는 Webhook 시크릿을 지원하지 않습니다. 페이로드를 보호하고 CI의 하이재킹을 방지하기 위해 코드로 된 Pipelines는 Bitbucket Cloud IP 주소 목록을 가져와서 웹 후크 수신이 해당 IP 주소에서만 수신되도록 합니다.

      • 기본 동작을 비활성화하려면 Pipelines에서 bitbucket-cloud-check-source-ip 키pipelines-as-code 네임스페이스에 대한 Code 구성 맵으로 false 로 설정합니다.
      • 안전한 IP 주소 또는 네트워크를 추가로 허용하려면 pipelines-as-code 네임스페이스에 대한 코드 구성 맵으로 Pipeline의 bitbucket-cloud-additional-source-ip 키에 쉼표로 구분된 값으로 추가합니다.
  2. 선택 사항: 기존 리포지토리 CR의 경우 여러 Bitbucket Cloud Webhook 시크릿을 추가하거나 삭제된 보안을 대신 제공합니다.

    1. tkn pac CLI 툴을 사용하여 Webhook를 추가합니다.

      예: tkn pac CLI를 사용하여 추가 Webhook 추가

      $ tkn pac webhook add -n repo-pipelines

      대화형 출력 샘플

      ✓ Setting up Bitbucket Webhook for Repository https://bitbucket.org/workspace/repo
      ? Please enter your bitbucket cloud username:  <username>
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ✓ Webhook has been created on repository workspace/repo
      🔑 Secret workspace-repo has been updated with webhook secret in the repo-pipelines namespace.

      참고

      tkn pac webhook add 명령에 [-n <namespace>] 옵션을 기본 네임스페이스 이외의 네임스페이스에 있는 경우에만 사용합니다.

    2. 기존 OpenShift Secret 오브젝트에서 webhook.secret 키를 업데이트합니다.
  3. 선택 사항: 기존 리포지토리 CR의 경우 개인 액세스 토큰을 업데이트합니다.

    • tkn pac CLI 툴을 사용하여 개인 액세스 토큰을 업데이트합니다.

      예: tkn pac CLI를 사용하여 개인 액세스 토큰 업데이트

      $ tkn pac webhook update-token -n repo-pipelines

      대화형 출력 샘플

      ? Please enter your personal access token:  ****************************************
      🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

      참고

      기본 네임스페이스 이외의 네임스페이스에 Repository CR이 있는 경우에만 tkn pac webhook update-token 명령에 [-n <namespace>] 옵션을 사용합니다.

    • 또는 Repository CR을 수정하여 개인 액세스 토큰을 업데이트합니다.

      1. 리포지토리 CR에서 시크릿 이름을 찾습니다.

        ...
        spec:
          git_provider:
            user: "<BITBUCKET_USERNAME>"
            secret:
              name: "bitbucket-cloud-token"
              key: "provider.token"
        ...
      2. oc patch 명령을 사용하여 $target_namespace 네임스페이스에서 $password 값을 업데이트합니다.

        $ oc -n $target_namespace patch secret bitbucket-cloud-token -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

3.8.9. Pipeline을 Bitbucket Server에서 Code로 사용

조직 또는 프로젝트에서 Bitbucket Server를 기본 플랫폼으로 사용하는 경우 Bitbucket Server에서 Webhook와 함께 리포지토리에 대한 코드로 Pipeline을 사용할 수 있습니다.

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.
  • Bitbucket Server에서 프로젝트 관리자로서 개인 액세스 토큰을 생성하고 사본을 대체 위치에 저장합니다.

    참고
    • 토큰에는 PROJECT_ADMINREPOSITORY_ADMIN 권한이 있어야 합니다.
    • 토큰은 가져오기 요청에서 분기된 리포지토리에 액세스할 수 있어야 합니다.

절차

  1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다.

    $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
  2. Bitbucket Server에서 다음 단계를 수행합니다.

    1. Bitbucket Data Center 리포지토리의 왼쪽 탐색 창을 사용하여 Repository settings > Webhooks 로 이동하고 Webhook 추가 를 클릭합니다.
    2. 제목을 설정합니다. 예를 들면 "Pipelines as Code"입니다.
    3. URL 을 코드 컨트롤러 공용 URL로 파이프라인에 설정합니다.
    4. 웹 후크 보안을 추가하고 사본을 대체 위치에 저장합니다. 로컬 시스템에 openssl 이 설치된 경우 다음 명령을 사용하여 임의의 시크릿을 생성합니다.

      $ openssl rand -hex 20
    5. 다음 이벤트를 선택합니다.

      • 리포지토리: 푸시
      • repository: 수정
      • 가져오기 요청: 열기
      • 가져오기 요청: 소스 분기 업데이트
      • 풀 요청: 주석 추가
    6. 저장을 클릭합니다.
  3. OpenShift 클러스터에서 대상 네임스페이스에 app 암호를 사용하여 Secret 오브젝트를 생성합니다.

    $ oc -n target-namespace create secret generic bitbucket-server-webhook-config \
      --from-literal provider.token="<PERSONAL_TOKEN>" \
      --from-literal webhook.secret="<WEBHOOK_SECRET>"
  4. 리포지토리 CR을 생성합니다.

    예: 리포지토리 CR

    ---
      apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
      kind: Repository
      metadata:
        name: my-repo
        namespace: target-namespace
      spec:
        url: "https://bitbucket.com/workspace/repo"
        git_provider:
          url: "https://bitbucket.server.api.url/rest" 1
          user: "<BITBUCKET_USERNAME>" 2
          secret: 3
            name: "bitbucket-server-webhook-config"
            key: "provider.token" # Set this if you have a different key in your secret
          webhook_secret:
            name: "bitbucket-server-webhook-config"
            key: "webhook.secret" # Set this if you have a different key for your secret

    1
    /api/v1.0 접미사가 없는 올바른 Bitbucket Server API URL이 있는지 확인합니다. 일반적으로 기본 설치에는 /rest 접미사가 있습니다.
    2
    소유자 파일에서 ACCOUNT_ID 만 사용자를 참조할 수 있습니다.
    3
    코드 파이프라인은 git_provider.secret 사양에서 참조하는 시크릿과 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.
    참고

    Bitbucket Server에서 tkn pac create 및 tkn pac 부트스트랩 명령이 지원되지 않습니다.

3.8.10. 사용자 정의 인증서를 사용하여 파이프라인을 Code로 연결

개인 서명 또는 사용자 정의 인증서로 액세스할 수 있는 Git 리포지토리를 사용하여 코드로 Pipeline을 구성하려면 인증서를 코드로 노출할 수 있습니다.

절차

  • Red Hat OpenShift Pipelines Operator를 사용하여 코드로 Pipeline을 설치한 경우 프록시 오브젝트를 사용하여 사용자 정의 인증서를 클러스터에 추가할 수 있습니다. Operator는 Pipeline을 Code로 포함하여 모든 Red Hat OpenShift Pipelines 구성 요소 및 워크로드에서 인증서를 노출합니다.

3.8.11. 파이프라인과 함께 Repository CRD 사용

Repository CR(사용자 정의 리소스)에는 다음과 같은 주요 기능이 있습니다.

  • URL의 이벤트 처리에 대해 파이프라인을 코드로 알립니다.
  • Pipeline을 코드로 파이프라인 실행의 네임스페이스에 대해 알립니다.
  • Webhook 메서드를 사용하는 경우 Git 공급자 플랫폼에 필요한 API 시크릿, 사용자 이름 또는 API URL을 참조합니다.
  • 리포지토리의 마지막 파이프라인 실행 상태를 제공합니다.

tkn pac CLI 또는 기타 대체 방법을 사용하여 대상 네임스페이스 내에 Repository CR을 생성할 수 있습니다. 예를 들면 다음과 같습니다.

cat <<EOF|kubectl create -n my-pipeline-ci -f- 1

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: project-repository
spec:
  url: "https://github.com/<repository>/<project>"
EOF
1
my-pipeline-ci 는 대상 네임스페이스입니다.

https://github.com/<repository>/<project >와 같은 URL에서 발생하는 이벤트가 있을 때마다 코드로서 Pipeline이 이를 일치시키고 파이프라인 실행이 .tekton / 디렉터리의 콘텐츠와 일치하도록 <repository>/<project > 리포지토리의 콘텐츠를 확인하기 시작합니다.

참고
  • 소스 코드 리포지토리와 연결된 파이프라인이 실행되는 동일한 네임스페이스에 Repository CRD를 생성해야 합니다. 다른 네임스페이스를 대상으로 지정할 수 없습니다.
  • 여러 Repository CRD가 동일한 이벤트와 일치하는 경우 Code로 Pipeline은 가장 오래된 이벤트만 처리합니다. 특정 네임스페이스와 일치해야 하는 경우 pipelinesascode.tekton.dev/target-namespace: "<mynamespace>" 주석을 추가합니다. 이러한 명시적 대상 지정을 통해 악의적인 작업자가 액세스 권한이 없는 네임스페이스에서 파이프라인 실행을 실행할 수 없습니다.

3.8.11.1. 리포지토리 CRD에서 동시성 제한 설정

리포지토리 CRD의 concurrency_limit 사양을 사용하여 리포지토리에 대해 동시에 실행되는 최대 파이프라인 실행 수를 정의할 수 있습니다.

...
spec:
  concurrency_limit: <number>
  ...

이벤트와 일치하는 파이프라인 실행이 여러 개인 경우 이벤트 시작과 일치하는 파이프라인이 알파벳순으로 실행됩니다.

예를 들어 .tekton 디렉터리에 세 개의 파이프라인 실행이 있고 리포지토리 구성에서 concurrency_limit1 인 가져오기 요청을 생성하는 경우 모든 파이프라인 실행이 알파벳순으로 실행됩니다. 언제든지 한 개의 파이프라인 실행만 실행 중이고 나머지는 대기열에 있습니다.

3.8.12. 파이프라인을 코드 해석기로 사용

코드 확인 프로그램으로 Pipeline을 사용하면 실행 중인 파이프라인 실행이 다른 파이프라인과 충돌하지 않습니다.

파이프라인 및 파이프라인 실행을 분할하려면 파일을 .tekton/ 디렉터리 또는 해당 하위 디렉터리에 저장합니다.

코드로서 파이프라인이 .tekton/ 디렉터리에 있는 YAML 파일에 있는 작업 또는 파이프라인에 대한 참조로 파이프라인 실행을 관찰하는 경우 코드로는 참조된 작업을 자동으로 해결하여 PipelineRun 오브젝트에 포함된 사양으로 단일 파이프라인 실행을 제공합니다.

코드로 Pipeline 또는 PipelineSpec 정의에서 참조된 작업을 확인할 수 없는 경우 클러스터에 변경 사항을 적용하기 전에 실행이 실패합니다. Git 공급자 플랫폼에서 문제와 Repository CR이 있는 대상 네임스페이스의 이벤트 내부에서 확인할 수 있습니다.

해결자는 다음 유형의 작업을 관찰하는 경우 확인을 건너뜁니다.

  • 클러스터 작업에 대한 참조입니다.
  • 작업 또는 파이프라인 번들입니다.
  • tekton.dev/ 접두사가 없는 API 버전이 있는 사용자 지정 작업입니다.

해결자는 변환 없이 이러한 작업을 문자 그대로 사용합니다.

가져오기 요청에 보내기 전에 파이프라인 실행을 로컬에서 테스트하려면 tkn pac resolve 명령을 사용합니다.

원격 파이프라인 및 작업을 참조할 수도 있습니다.

3.8.12.1. 파이프라인에서 코드로 원격 작업 주석 사용

코드로 파이프라인은 파이프라인 실행에서 주석을 사용하여 원격 작업 또는 파이프라인 가져오기를 지원합니다. 파이프라인 실행에서 원격 작업 또는 PipelineRun 또는 PipelineSpec 오브젝트의 파이프라인을 참조하는 경우, Code resolver로서 Pipeline이 자동으로 포함됩니다. 원격 작업을 가져오거나 구문 분석하는 동안 오류가 있는 경우 코드로 인해 작업 처리가 중지됩니다.

원격 작업을 포함하려면 주석의 다음 예제를 참조하십시오.

Tekton Hub에서 원격 작업 참조

  • Tekton Hub에서 단일 원격 작업을 참조합니다.

    ...
      pipelinesascode.tekton.dev/task: "git-clone" 1
    ...
    1
    Code로 파이프라인에는 Tekton Hub의 최신 버전의 작업이 포함됩니다.
  • Tekton Hub에서 여러 원격 작업 참조

    ...
      pipelinesascode.tekton.dev/task: "[git-clone, golang-test, tkn]"
    ...
  • -<NUMBER > 접미사를 사용하여 Tekton Hub에서 여러 원격 작업을 참조합니다.

    ...
      pipelinesascode.tekton.dev/task: "git-clone"
      pipelinesascode.tekton.dev/task-1: "golang-test"
      pipelinesascode.tekton.dev/task-2: "tkn" 1
    ...
    1
    기본적으로 Code로 Pipeline은 Tekton Hub에서 가져올 최신 작업으로 문자열을 해석합니다.
  • Tekton Hub에서 특정 버전의 원격 작업을 참조합니다.

    ...
      pipelinesascode.tekton.dev/task: "[git-clone:0.1]" 1
    ...
    1
    Tekton Hub에서 git-clone 원격 작업의 0.1 버전을 나타냅니다.

URL을 사용하는 원격 작업

...
  pipelinesascode.tekton.dev/task: "<https://remote.url/task.yaml>" 1
...

1
원격 작업의 공용 URL입니다.
참고

리포지토리 내부의 YAML 파일에서 작업을 참조합니다.

...
pipelinesascode.tekton.dev/task: "<share/tasks/git-clone.yaml>" 1
...

1
작업 정의가 포함된 로컬 파일의 상대 경로입니다.

3.8.12.2. 파이프라인에서 코드로 원격 파이프라인 주석 사용

원격 파이프라인 주석을 사용하여 여러 리포지토리에 파이프라인 정의를 공유할 수 있습니다.

...
    pipelinesascode.tekton.dev/pipeline: "<https://git.provider/raw/pipeline.yaml>" 1
...
1
원격 파이프라인 정의에 대한 URL입니다. 동일한 리포지토리 내에 있는 파일의 위치를 제공할 수도 있습니다.
참고

주석을 사용하여 하나의 파이프라인 정의만 참조할 수 있습니다.

3.8.13. 파이프라인을 코드로 사용하여 파이프라인 실행 생성

코드로 Pipeline을 사용하여 파이프라인을 실행하려면 리포지토리의 .tekton/ 디렉터리에서 파이프라인 정의 또는 템플릿을 YAML 파일로 생성할 수 있습니다. 원격 URL을 사용하여 다른 리포지토리의 YAML 파일을 참조할 수 있지만 파이프라인 실행은 .tekton/ 디렉터리가 포함된 리포지토리의 이벤트에 의해서만 트리거됩니다.

코드 확인자인 파이프라인은 외부 종속 항목 없이 단일 파이프라인 실행으로 모든 작업과 함께 실행되는 번들입니다.

참고
  • 파이프라인의 경우 사양 또는 분리된 Pipeline 오브젝트와 함께 하나 이상의 파이프라인 실행을 사용합니다.
  • 작업의 경우 파이프라인 내부에 작업 사양을 포함하거나 이를 Task 오브젝트로 별도로 정의합니다.

커밋 및 URL 매개 변수화

{{<var>}} 형식으로 동적, 확장 가능한 변수를 사용하여 커밋 및 URL의 매개변수를 지정할 수 있습니다. 현재 다음 변수를 사용할 수 있습니다.

  • {{repo_owner}}: 리포지토리 소유자입니다.
  • {{REPO_NAME}}: 저장소 이름입니다.
  • {{repo_url}}: 리포지토리 전체 URL입니다.
  • {{revision}}: 커밋의 전체 SHA 리버전입니다.
  • {{sender}}: 커밋 발신자의 사용자 이름 또는 계정 ID입니다.
  • {{source_branch}}: 이벤트가 시작된 분기 이름입니다.
  • {{target_branch}}: 이벤트 대상이 되는 분기 이름입니다. 푸시 이벤트의 경우 source_branch 와 동일합니다.
  • {{pull_request_number}}: pull_request 이벤트 유형에 대해서만 정의된 가져오기 또는 병합 요청 번호입니다.
  • {{git_auth_secret}}: 개인 리포지터리를 확인하기 위해 Git 공급자의 토큰으로 자동 생성된 시크릿 이름입니다.

파이프라인 실행에 이벤트 일치

파이프라인 실행에서 특수 주석을 사용하여 각 파이프라인과 다른 Git 공급자 이벤트를 일치시킬 수 있습니다. 이벤트와 일치하는 Pipeline이 여러 개 있는 경우 Code가 병렬로 실행되고 파이프라인 실행이 완료되면 Pipeline이 Git 공급자에 결과를 게시합니다.

파이프라인 실행에 가져오기 이벤트 일치

다음 예제를 사용하여 기본 분기를 대상으로 하는 pull_request 이벤트와 pipeline-pr- main 파이프라인을 일치시킬 수 있습니다.

...
  metadata:
    name: pipeline-pr-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]" 1
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
...
1
쉼표로 구분된 항목을 추가하여 여러 분기를 지정할 수 있습니다. 예: "[main, release-nightly]" 입니다. 또한 다음을 지정할 수 있습니다.
  • "refs/heads/main"과 같은 분기에 대한 전체 참조
  • "refs/heads/\*"와 같은 패턴 일치가 있는 글러
  • "refs/tags/1.\*"와 같은 태그

파이프라인 실행에 푸시 이벤트 일치

다음 예제를 사용하여 refs/heads/main 브랜치를 대상으로 하는 push 이벤트와 pipeline-push-on-main 파이프라인을 일치시킬 수 있습니다.

...
  metadata:
    name: pipeline-push-on-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]" 1
    pipelinesascode.tekton.dev/on-event: "[push]"
...
1
쉼표로 구분된 항목을 추가하여 여러 분기를 지정할 수 있습니다. 예: "[main, release-nightly]" 입니다. 또한 다음을 지정할 수 있습니다.
  • "refs/heads/main"과 같은 분기에 대한 전체 참조
  • "refs/heads/\*"와 같은 패턴 일치가 있는 글러
  • "refs/tags/1.\*"와 같은 태그

고급 이벤트 일치

코드인 파이프라인은 고급 이벤트 일치에 대한 CEL(Common Expression Language) 기반 필터링 사용을 지원합니다. 파이프라인 실행에 pipelinesascode.tekton.dev/on-cel-expression 주석이 있는 경우 Code로 Pipeline은 CEL 표현식을 사용하고 on-target-branch 주석을 건너뜁니다. 간단한 on-target-branch 주석 일치와 비교하여 CEL 표현식은 복잡한 필터링 및 부정을 허용합니다.

파이프라인과 함께 CEL 기반 필터링을 코드로 사용하려면 주석의 다음 예를 고려하십시오.

  • 기본 분기를 대상으로 pull_request 이벤트를 일치시키고 wip 분기에서 들어오는 경우 다음을 수행합니다.

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request" && target_branch == "main" && source_branch == "wip"
    ...
  • 경로가 변경된 경우에만 파이프라인을 실행하려면 .pathChanged 접미사 함수를 와일드카드 패턴과 함께 사용하면 됩니다.

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request" && "docs/\*.md".pathChanged() 1
    ...
    1
    docs 디렉터리의 모든 마크다운 파일과 일치합니다.
  • 제목 [DOWNSTREAM] 으로 시작하는 모든 풀 요청을 일치시킵니다.

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request && event_title.startsWith("[DOWNSTREAM]")
    ...
  • pull_request 이벤트에서 파이프라인을 실행하되 실험적인 분기를 건너뛰려면 다음을 수행합니다.

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request" && target_branch != experimental"
    ...

코드로 Pipeline을 사용하는 동안 고급 CEL 기반 필터링의 경우 다음 필드 및 접미사 함수를 사용할 수 있습니다.

  • 이벤트: push 또는 pull_request 이벤트
  • target_branch: 대상 분기입니다.
  • source_branch: pull_request 이벤트의 origin 분기입니다. 푸시 이벤트의 경우 target_branch 와 동일합니다.
  • event_title: 푸시 이벤트의 커밋 제목과 pull_request 이벤트에 대한 풀 또는 병합 요청의 제목과 같은 이벤트의 제목을 찾습니다. 현재는 GitHub, Gitlab, Bitbucket Cloud만 지원되는 공급업체입니다.
  • .pathChanged: 문자열에 대한 접미사 함수입니다. 문자열은 경로가 변경되었는지 확인하는 경로의 glob일 수 있습니다. 현재는 GitHub 및 Gitlab만 공급업체로 지원됩니다.

Github API 작업에 임시 GitHub 앱 토큰 사용

Pipeline에서 생성한 임시 설치 토큰을 GitHub App에서 Code로 사용하여 GitHub API에 액세스할 수 있습니다. 토큰 값은 git-provider-token 키의 개인 리포지토리에 대해 생성된 임시 {{git_auth_secret}} 동적 변수에 저장됩니다.

예를 들어 가져오기 요청에 주석을 추가하려면 Pipelines를 코드 주석으로 사용하여 Tekton Hub의 github-add-comment 작업을 사용할 수 있습니다.

...
  pipelinesascode.tekton.dev/task: "github-add-comment"
...

그런 다음 tasks 섹션에 작업을 추가하거나 파이프라인 실행 정의의 finally 작업에 추가할 수 있습니다.

[...]
tasks:
  - name:
      taskRef:
        name: github-add-comment
      params:
        - name: REQUEST_URL
          value: "{{ repo_url }}/pull/{{ pull_request_number }}" 1
        - name: COMMENT_OR_FILE
          value: "Pipelines as Code IS GREAT!"
        - name: GITHUB_TOKEN_SECRET_NAME
          value: "{{ git_auth_secret }}"
        - name: GITHUB_TOKEN_SECRET_KEY
          value: "git-provider-token"
...
1
동적 변수를 사용하면 리포지토리에서 가져오기 요청에 이 스니펫 템플릿을 재사용할 수 있습니다.
참고

GitHub 앱에서 생성된 설치 토큰은 8시간 동안 사용할 수 있으며 클러스터에서 다르게 구성되지 않는 한 이벤트가 시작된 리포지토리에 범위가 지정됩니다.

추가 리소스

3.8.14. 파이프라인을 코드로 사용하여 파이프라인 실행 실행

기본 구성을 사용하면 코드에서 파이프라인은 가져오기 요청 또는 푸시와 같은 지정된 이벤트가 리포지터리에서 발생하는 경우 리포지토리의 기본 리포지토리 분기의 .tekton/ 디렉터리에서 모든 파이프라인을 실행합니다. 예를 들어 기본 분기에서 파이프라인 실행의 주석 pipelinesascode.tekton.dev/on-event: "[pull_request]" 가 있는 경우 가져오기 요청 이벤트가 발생할 때마다 실행됩니다.

가져오기 요청 또는 병합 요청이 있는 경우 Code로 Pipeline은 가져오기 요청 작성자가 다음 조건을 충족하는 경우 기본 분기 이외의 분기에서 파이프라인도 실행합니다.

  • 작성자는 리포지토리의 소유자입니다.
  • 작성자는 리포지토리의 협업자입니다.
  • 작성자는 리포지토리 조직의 공개 멤버입니다.
  • 가져오기 요청 작성자는 리포지토리의 GitHub 구성에 정의된 대로 기본 분기의 리포지토리 루트에 있는 OWNER 파일에 나열됩니다. 또한 가져오기 요청 작성자가 승인 자 또는 검토자 섹션에 추가됩니다. 예를 들어 작성자가 승인자 섹션에 나열되면 해당 작성자가 생성한 가져오기 요청이 파이프라인 실행을 시작합니다.
...
  approvers:
    - approved
...

가져오기 요청 작성자가 요구 사항을 충족하지 않으면 요구 사항을 충족하는 다른 사용자가 가져오기 요청에 대해 /ok-to-test 를 처리하고 파이프라인 실행을 시작할 수 있습니다.

파이프라인 실행 실행

파이프라인 실행은 이벤트를 생성한 리포지토리와 연결된 Repository CRD의 네임스페이스에서 항상 실행됩니다.

tkn pac CLI 툴을 사용하여 파이프라인 실행의 실행을 확인할 수 있습니다.

  • 마지막 파이프라인 실행을 추적하려면 다음 예제를 사용합니다.

    $ tkn pac logs -n <my-pipeline-ci> -L 1
    1
    my-pipeline-ciRepository CRD의 네임스페이스입니다.
  • 대화형으로 실행되는 모든 파이프라인 실행을 추적하려면 다음 예제를 사용합니다.

    $ tkn pac logs -n <my-pipeline-ci> 1
    1
    my-pipeline-ciRepository CRD의 네임스페이스입니다. 마지막이 아닌 다른 파이프라인 실행을 확인해야 하는 경우 tkn pac logs 명령을 사용하여 리포지토리에 연결된 PipelineRun 을 선택할 수 있습니다.

GitHub App을 사용하여 파이프라인을 코드로 구성한 경우 코드로 파이프라인은 GitHub 앱의 검사 탭에 URL을 게시합니다. URL을 클릭하고 파이프라인 실행을 따를 수 있습니다.

파이프라인 실행 다시 시작

새 커밋을 분기에 전송하거나 가져오기 요청을 높이는 등 이벤트 없이 파이프라인 실행을 재시작할 수 있습니다. GitHub 앱에서 확인 탭으로 이동하여 다시 실행을 클릭합니다.

가져오기 또는 병합 요청을 대상으로 하는 경우 가져오기 요청 내부에 다음 주석을 사용하여 모든 또는 특정 파이프라인 실행을 다시 시작합니다.

  • /retest 주석은 모든 파이프라인 실행을 재시작합니다.
  • /retest <pipelinerun-name> 주석에서 특정 파이프라인 실행을 다시 시작합니다.
  • /cancel 주석은 모든 파이프라인 실행이 취소됩니다.
  • /cancel <pipelinerun-name&gt; 주석은 특정 파이프라인 실행이 취소됩니다.

주석의 결과는 GitHub 앱의 확인 탭에 표시됩니다.

3.8.15. 파이프라인을 코드로 사용하여 파이프라인 실행 상태 모니터링

컨텍스트 및 지원되는 툴에 따라 다양한 방법으로 파이프라인 실행 상태를 모니터링할 수 있습니다.

GitHub 앱의 상태

파이프라인 실행이 완료되면 Check 탭에 파이프라인의 각 작업이 수행된 기간 및 tkn pipelinerun describe 명령의 출력에 대한 제한된 정보가 포함되어 있습니다.

로그 오류 스니펫

코드로 파이프라인 작업 중 하나에서 오류를 감지하면 첫 번째 실패한 작업의 작업 분류에 있는 마지막 3행으로 구성된 작은 스니펫이 표시됩니다.

참고

코드로 파이프라인을 사용하면 파이프라인 실행을 살펴보고 시크릿 값을 숨겨진 문자로 교체하여 시크릿 누출을 방지할 수 있습니다. 그러나 코드로 Pipeline은 작업 공간 및 envFrom 소스에서 발생하는 시크릿을 숨길 수 없습니다.

로그 오류 조각에 대한 주석

코드 구성 맵으로 파이프라인에서 error-detection-from-container-logs 매개변수를 true 로 설정하면 Code에서 컨테이너 로그의 오류를 감지하고 오류가 발생한 풀 요청에 주석으로 추가합니다.

중요

이 기능은 기술 프리뷰에 있습니다.

현재 코드로 Pipeline은 오류가 makefile 또는 다음 형식의 grep 출력과 같은 간단한 사례만 지원합니다.

<filename>:<line>:<column>: <error message>

error-detection-simple-regexp 필드로 오류를 감지하는 데 사용되는 정규식을 사용자 지정할 수 있습니다. 정규식에서는 이름이 지정된 그룹을 사용하여 일치 항목을 지정하는 방법에 대한 유연성을 제공합니다. 일치해야 하는 그룹은 파일 이름, 줄, 오류입니다. 기본 정규식에 대한 코드 구성 맵으로 Pipeline을 볼 수 있습니다.

참고

기본적으로 코드인 Pipeline은 컨테이너 로그의 마지막 50행만 검사합니다. error-detection-max-number-of-lines 필드에서 이 값을 늘리거나 무제한 행 수에 대해 -1 을 설정할 수 있습니다. 그러나 이러한 구성은 감시자의 메모리 사용량을 늘릴 수 있습니다.

Webhook 상태

Webhook의 경우 이벤트가 가져오기 요청인 경우 가져오기 또는 병합 요청에 대한 주석으로 상태가 추가됩니다.

실패

네임스페이스가 Repository CRD와 일치하는 경우 Code로 Pipeline은 네임스페이스 내부의 Kubernetes 이벤트에서 실패 로그 메시지를 내보냅니다.

Repository CRD와 관련된 상태

파이프라인 실행에 대한 마지막 5개의 상태 메시지는 Repository 사용자 정의 리소스 내부에 저장됩니다.

$ oc get repo -n <pipelines-as-code-ci>
NAME                  URL                                                        NAMESPACE             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
pipelines-as-code-ci   https://github.com/openshift-pipelines/pipelines-as-code   pipelines-as-code-ci   True        Succeeded   59m         56m

tkn pac describe 명령을 사용하면 리포지토리 및 해당 메타데이터와 연결된 실행 상태를 추출할 수 있습니다.

알림

코드로 파이프라인은 알림을 관리하지 않습니다. 알림이 필요한 경우 파이프라인의 finally 기능을 사용하십시오.

3.8.16. 파이프라인을 코드로 사용하여 개인 리포지토리 사용

코드로 파이프라인은 사용자 토큰으로 대상 네임스페이스에서 보안을 생성하거나 업데이트하여 개인 리포지토리를 지원합니다. Tekton Hub의 git-clone 작업은 사용자 토큰을 사용하여 개인 리포지토리를 복제합니다.

코드로서 파이프라인이 대상 네임스페이스에서 새 파이프라인 실행을 생성할 때마다 pac-gitauth-<REPOSITORY_OWNER>-<REPOSITORY_NAME>-<RANDOM_STRING > 형식으로 시크릿을 생성하거나 업데이트합니다.

그런 다음 파이프라인 실행 및 파이프라인 정의에서 basic-auth 작업 영역을 사용하여 보안을 참조해야 합니다. 그러면 git-clone 작업으로 전달됩니다.

...
  workspace:
  - name: basic-auth
    secret:
      secretName: "{{ git_auth_secret }}"
...

파이프라인에서는 재사용할 git-clone 작업의 basic-auth 작업 영역을 참조할 수 있습니다.

...
workspaces:
  - name basic-auth
params:
    - name: repo_url
    - name: revision
...
tasks:
  workspaces:
    - name: basic-auth
      workspace: basic-auth
  ...
  tasks:
  - name: git-clone-from-catalog
      taskRef:
        name: git-clone 1
      params:
        - name: url
          value: $(params.repo_url)
        - name: revision
          value: $(params.revision)
...
1
git-clone 작업은 basic-auth 작업 영역을 선택하고 이를 사용하여 개인 리포지토리를 복제합니다.

파이프라인에 코드 구성 맵으로 필요한 대로 secret-auto-create 플래그를 false 또는 true 값으로 설정하여 이 구성을 수정할 수 있습니다.

3.8.17. 파이프라인을 코드로 사용하여 파이프라인 실행 정리

사용자 네임스페이스에는 많은 파이프라인 실행이 있을 수 있습니다. max-keep-runs 주석을 설정하면 이벤트와 일치하는 제한된 수의 파이프라인 실행을 유지하도록 파이프라인을 Code로 구성할 수 있습니다. 예를 들면 다음과 같습니다.

...
  pipelinesascode.tekton.dev/max-keep-runs: "<max_number>" 1
...
1
코드로서 파이프라인은 성공적인 실행이 완료된 직후 정리를 시작하여 주석을 사용하여 구성된 최대 파이프라인 실행 수만 유지합니다.
참고
  • 코드로 파이프라인은 실행 중인 파이프라인 정리를 생략하지만 파이프라인은 알 수 없는 상태로 실행됩니다.
  • 코드로 파이프라인은 실패한 가져오기 요청 정리를 건너뜁니다.

3.8.18. 파이프라인에서 코드로 들어오는 Webhook 사용

들어오는 웹 후크 URL과 공유 보안을 사용하여 리포지토리에서 파이프라인 실행을 시작할 수 있습니다.

들어오는 Webhook를 사용하려면 Repository CRD의 spec 섹션에서 다음을 지정합니다.

  • 코드로 Pipeline이 일치하는 들어오는 웹 후크 URL입니다.
  • Git 공급자 및 사용자 토큰입니다. 현재 코드로 Pipeline은 github,gitlab, bitbucket-cloud 를 지원합니다.

    참고

    GitHub 앱의 컨텍스트에서 들어오는 Webhook URL을 사용하는 경우 토큰을 지정해야 합니다.

  • 대상 분기와 들어오는 Webhook URL의 시크릿입니다.

예: 수신 Webhook가 있는 Repository CRD

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: repo
  namespace: ns
spec:
  url: "https://github.com/owner/repo"
  git_provider:
    type: github
    secret:
      name: "owner-token"
  incoming:
    - targets:
      - main
      secret:
        name: repo-incoming-secret
      type: webhook-url

예: 들어오는 Webhook의 repo-incoming-secret 보안

apiVersion: v1
kind: Secret
metadata:
  name: repo-incoming-secret
  namespace: ns
type: Opaque
stringData:
  secret: <very-secure-shared-secret>

Git 리포지토리의 .tekton 디렉터리에 있는 파이프라인 실행을 트리거하려면 다음 명령을 사용합니다.

$ curl -X POST 'https://control.pac.url/incoming?secret=very-secure-shared-secret&repository=repo&branch=main&pipelinerun=target_pipelinerun'

코드인 파이프라인은 들어오는 URL과 일치하고 푸시 이벤트로 처리합니다. 그러나 코드로 파이프라인은 이 명령으로 트리거된 파이프라인 실행의 상태를 보고하지 않습니다.

보고서 또는 알림을 가져오려면 파이프라인에 finally 작업과 함께 직접 추가합니다. 또는 tkn pac CLI 툴을 사용하여 Repository CRD를 검사할 수도 있습니다.

3.8.19. 코드 구성으로 Pipeline 사용자 정의

클러스터 관리자는 Pipeline을 코드로 사용자 정의하도록 pipelines-as-code 네임스페이스에서 pipelines-as-code 구성 맵을 사용하여 다음 매개변수를 구성할 수 있습니다.

표 3.8. 코드 구성으로 Pipeline 사용자 정의
매개변수설명기본값

application-name

애플리케이션 이름입니다. 예를 들어 GitHub Checks 레이블에 표시되는 이름입니다.

"pipelines as Code CI"

max-keep-days

실행된 파이프라인 실행이 pipelines-as-code 네임스페이스에 유지되는 일 수입니다.

ConfigMap 설정은 사용자 GitHub 리포지토리의 파이프라인 실행 주석에 의해 제어되는 사용자 파이프라인 실행의 정리에는 영향을 미치지 않습니다.

해당 없음

secret-auto-create

GitHub 애플리케이션에서 생성된 토큰을 사용하여 시크릿을 자동으로 생성할지 여부를 나타냅니다. 그런 다음 이 시크릿을 개인 리포지토리와 함께 사용할 수 있습니다.

enabled

remote-tasks

활성화하면 파이프라인 실행 주석의 원격 작업을 허용합니다.

enabled

hub-url

Tekton Hub API 의 기본 URL입니다.

https://hub.tekton.dev/

hub-catalog-name

Tekton Hub 카탈로그 이름입니다.

tekton

tekton-dashboard-url

Tekton Hub 대시보드의 URL입니다. Pipeline as Code는 이 URL을 사용하여 Tekton Hub 대시보드에서 PipelineRun URL을 생성합니다.

해당 없음

bitbucket-cloud-check-source-ip

공용 Bitbucket의 IP 범위를 쿼리하여 서비스 요청의 보안 여부를 나타냅니다. 매개변수의 기본값을 변경하면 보안 문제가 발생할 수 있습니다.

enabled

bitbucket-cloud-additional-source-ip

쉼표로 구분된 추가 IP 범위 또는 네트워크 세트를 제공할지 여부를 나타냅니다.

해당 없음

max-keep-run-up-limit

파이프라인 실행의 max-keep-run 값에 대한 최대 제한입니다.

해당 없음

default-max-keep-runs

파이프라인 실행의 max-keep-run 값에 대한 기본 제한입니다. 정의된 경우 max-keep-run 주석이 없는 모든 파이프라인 실행에 값이 적용됩니다.

해당 없음

auto-configure-new-github-repo

새 GitHub 리포지토리를 자동으로 구성합니다. Code로 Pipeline은 네임스페이스를 설정하고 리포지토리에 대한 사용자 정의 리소스를 생성합니다. 이 매개변수는 GitHub 애플리케이션에서만 지원됩니다.

disabled

auto-configure-repo-namespace-template

auto-configure-new-github-repo 가 활성화된 경우 새 리포지토리의 네임스페이스를 자동으로 생성하도록 템플릿을 구성합니다.

{repo_name}-pipelines

error-log-snippet

파이프라인의 오류와 함께 실패한 작업에 대한 로그 스니펫 보기를 활성화하거나 비활성화합니다. 파이프라인에서 데이터 누출의 경우 이 매개변수를 비활성화할 수 있습니다.

enabled

3.8.20. Code 명령 참조 파이프라인

tkn pac CLI 툴에서는 다음과 같은 기능을 제공합니다.

  • 코드 설치 및 구성으로 부트스트랩 파이프라인.
  • 새 Pipeline을 코드 리포지토리로 생성합니다.
  • 모든 Pipeline을 코드 리포지토리로 나열합니다.
  • Pipeline을 Code 리포지토리 및 관련 실행으로 설명합니다.
  • 시작하는 간단한 파이프라인 실행을 생성합니다.
  • Pipeline에서 코드로 실행한 것처럼 파이프라인 실행을 해결합니다.
작은 정보

테스트 및 실험용 기능에 해당하는 명령을 사용할 수 있으므로 애플리케이션 소스 코드가 포함된 Git 리포지토리를 변경할 필요가 없습니다.

3.8.20.1. 기본 구문

$ tkn pac [command or options] [arguments]

3.8.20.2. 글로벌 옵션

$ tkn pac --help

3.8.20.3. 유틸리티 명령

3.8.20.3.1. bootstrap
표 3.9. 코드 설치 및 구성으로 Pipeline 부트스트랩
명령설명

tkn pac 부트스트랩

GitHub 및 GitHub Enterprise와 같은 Git 리포지토리 호스팅 서비스 공급자의 코드로 Pipeline을 설치하고 구성합니다.

tkn pac bootstrap --nightly

파이프라인의 야간 빌드를 코드로 설치합니다.

tkn pac bootstrap --route-url <public_url_to_ingress_spec>

OpenShift 경로 URL을 덮어씁니다.

기본적으로 tkn pac 부트스트랩 은 OpenShift 경로를 탐지합니다. 이 경로는 코드 컨트롤러 서비스로 Pipeline과 자동으로 연결됩니다.

OpenShift Container Platform 클러스터가 없는 경우 Ingress 끝점을 가리키는 공용 URL을 요청합니다.

tkn pac bootstrap github-app

pipelines-as-code 네임스페이스에서 GitHub 애플리케이션 및 시크릿을 생성합니다.

3.8.20.3.2. 리포지터리
표 3.10. Pipeline을 코드 리포지토리로 관리
명령설명

tkn pac create repository

새 Pipeline을 Code 리포지터리로 생성하고 파이프라인 실행 템플릿을 기반으로 네임스페이스를 생성합니다.

tkn pac list

모든 Pipeline을 Code 리포지토리로 나열하고 연결된 실행의 마지막 상태를 표시합니다.

tkn pac repo describe

파이프라인을 코드 리포지토리로 설명하고 관련 실행을 설명합니다.

3.8.20.3.3. generate
표 3.11. Pipeline을 코드로 사용하여 파이프라인 실행 생성
명령설명

tkn pac generate

간단한 파이프라인 실행을 생성합니다.

소스 코드가 포함된 디렉터리에서 실행되는 경우 현재 Git 정보를 자동으로 탐지합니다.

또한 기본 언어 감지 기능을 사용하고 언어에 따라 추가 작업을 추가합니다.

예를 들어 리포지토리 루트에서 setup.py 파일을 감지하면 pylint 작업이 생성된 파이프라인 실행에 자동으로 추가됩니다.

3.8.20.3.4. resolve
표 3.12. Pipeline을 코드로 사용하여 파이프라인 실행 해결 및 실행
명령설명

tkn pac resolve

Pipeline이 서비스상의 코드로 Pipeline을 소유하고 있는 것처럼 파이프라인 실행을 실행합니다.

tkn pac resolve -f .tekton/pull-request.yaml | oc apply -f -

.tekton/pull-request.yaml 에서 템플릿을 사용하는 라이브 파이프라인 실행 상태를 표시합니다.

로컬 시스템에서 실행되는 Kubernetes 설치와 결합하여 새 커밋을 생성하지 않고 파이프라인 실행을 확인할 수 있습니다.

소스 코드 리포지토리에서 명령을 실행하면 현재 Git 정보를 감지하고 현재 버전 또는 분기와 같은 매개변수를 자동으로 해결합니다.

tkn pac resolve -f .tekton/pr.yaml -p revision=main -p repo_name=<repository_name>

Git 리포지토리에서 파생되는 기본 매개변수 값을 재정의하여 파이프라인 실행을 실행합니다.

-f 옵션은 디렉터리 경로를 수락하고 해당 디렉터리의 모든 .yaml 또는 .yml 파일에 tkn pac resolve 명령을 적용할 수도 있습니다. 동일한 명령에서 -f 플래그를 여러 번 사용할 수도 있습니다.

-p 옵션을 사용하여 매개변수 값을 지정하여 Git 리포지토리에서 수집된 기본 정보를 덮어쓸 수 있습니다. 예를 들어 Git 분기를 버전 및 다른 리포지토리 이름으로 사용할 수 있습니다.

3.8.21. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.