Azure DevOps 예약 파이프라인: UTC 기준 매일 밤 cron

Azure DevOps 파이프라인을 예약 실행하려면 YAML에 schedules: 블록을 추가하고, Azure Pipelines가 UTC로 읽는 cron: 표현식과 스케줄을 적용할 branches:를 지정하세요. 기본적으로 마지막으로 성공한 예약 실행 이후 바뀐 것이 없으면 예약 실행을 건너뛰므로, AI 영상을 시작하는 파이프라인처럼 매일 밤 반드시 실행되어야 하는 파이프라인에는 always: true를 추가하세요.

Azure 관련 내용은 Microsoft의 파이프라인 실행 스케줄 구성을 비롯해 출처에 나열한 다른 Azure Pipelines 문서에서, Sume 관련 내용은 Format 호출하기 (영문), 실행과 결과 (영문), 오류와 비용 (영문)에서 가져왔습니다. 모두 2026-09-28에 확인했습니다. Sume에는 Azure DevOps 전용 연동이 없으며, 파이프라인이 curl로 일반 HTTPS 호출을 한 번 보냅니다. GitLab에서 같은 작업을 하는 방법은 GitLab 파이프라인 스케줄: 매일 밤 AI 영상 작업 실행에서 다룹니다.

예약 파이프라인의 YAML은 어떤 모습인가요?

schedules: 아래의 각 항목에는 작은따옴표로 감싼 다섯 필드 cron:, displayName, include와 exclude 목록을 담은 branches, 그리고 기본값이 false인 불리언 두 개가 들어갑니다. always는 바뀐 것이 없어도 실행하게 하고, batch는 이전 실행이 아직 진행 중이면 스케줄이 새 실행을 시작하지 않게 합니다. 단, always가 true이면 예외입니다. 아래 파이프라인은 매일 05:00 UTC에 Sume Format 실행 하나를 시작합니다.

• trigger: none과 pr: none은 기본 CI 트리거와 PR 트리거를 끕니다.
• name은 실행 번호가 날짜로 시작하게 하며, Azure DevOps Services는 이 날짜를 UTC로 표시합니다. 스텝은 그 날짜로 Idempotency-Key를 만듭니다.
• -H @-는 curl이 헤더를 표준 입력에서 읽게 하고, --fail-with-body는 4xx나 5xx에서 오류를 반환하게 하면서도 Sume의 JSON 오류는 그대로 출력하게 합니다.

name: $(Date:yyyyMMdd).$(Rev:r) # the run number starts with the date
trigger: none
pr: none
schedules:
  - cron: '0 5 * * *' # 05:00 UTC every day
    displayName: Nightly video
    branches:
      include: [main]
    always: true # run even when nothing changed
jobs:
  - job: nightly_video
    timeoutInMinutes: 10
    steps:
      - bash: |
          DAY="${RUN_NUMBER%%.*}" # same date on every retry of this run
          printf 'Authorization: Bearer %s\n' "$SUME_API_KEY" |
            curl -sS --fail-with-body -H @- -H 'Content-Type: application/json' \
              -H "Idempotency-Key: nightly-recap-$DAY" \
              -d "{\"input\":{\"day\":\"$DAY\"},\"communication\":{\"webhook_url\":\"https://example.com/hooks/sume\"}}" \
              https://api.sume.com/v1/formats/acme/nightly-recap/runs
        retryCountOnTaskFailure: 2
        env:
          SUME_API_KEY: $(SUME_API_KEY) # a secret variable
          RUN_NUMBER: $(Build.BuildNumber)

예약 파이프라인이 왜 실행되지 않았나요?

먼저 파이프라인 컨텍스트 메뉴의 Scheduled runs를 확인하세요. 앞으로 최대 일주일 동안 예정된 예약 실행을 미리 보여 줍니다. 기대한 실행이 목록에 없거나, 목록에는 있는데 시작되지 않았다면 Microsoft 문서가 꼽는 원인은 다음과 같습니다.

API 키는 어디에 두어야 하나요?

YAML에는 절대 두지 말고 비밀 변수(secret variable)에 두세요. Microsoft는 비밀 값을 파이프라인 UI, 변수 그룹, 또는 Azure Key Vault에 연결된 변수 그룹에서 설정하라고 권장하며, Sume의 인증 문서도 키를 둘 수 있는 곳으로 CI 시크릿 저장소를 꼽습니다. 비밀 변수는 스크립트용 환경 변수로 복호화되지 않으므로, 스텝의 env:에서 변수를 매핑하세요. Microsoft는 일부 운영체제가 명령줄 인수를 로그에 남기므로 비밀 값을 명령줄로 넘기지 말라고도 말합니다. 예제는 그 대신 헤더를 파이프로 curl에 넘깁니다.

파이프라인이 두 번 실행되면 어떻게 되나요?

키가 날짜에서 나오므로 같은 날의 반복은 첫 실행을 재전송할 뿐입니다. Sume는 같은 키와 본문에 원래 영수증과 idempotency_hit: true를 담아 200으로 응답하므로, 두 번 청구되는 것은 없습니다. 반복은 실제로 일어납니다. 그날 누군가 수동으로 실행할 수도 있고, retryCountOnTaskFailure가 실패한 스텝을 재시도할 수도 있습니다. 이 설정은 실패한 스텝을 대기 시간을 늘려 가며 최대 10회 재시도하며, Microsoft의 표현을 빌리면 멱등성을 제공하지 않습니다. 나머지 재전송 사례는 AI 영상 API 멱등성 키에서 다루며, Sume Format 실행 실패에서 설명하듯 failed로 끝난 실행을 같은 날 다시 실행하려면 새 키가 필요합니다. 이 파이프라인에서는 다음을 지키세요.

• 그날의 input과 webhook_url은 고정하세요. 같은 키에 다른 본문을 보내면 409 idempotency_conflict가 돌아오고 아무것도 실행되지 않습니다.
• --fail-with-body는 모든 4xx에서 스텝을 실패시키므로, 스텝 재시도는 먼저 충전이 필요한 402처럼 다시 보내도 답이 바뀌지 않는 요청까지 다시 보냅니다. 이런 재전송에는 비용이 들지 않습니다. 생성 단계의 4xx는 아무것도 실행되지 않았고 아무것도 청구되지 않았다는 뜻입니다.

파이프라인이 영상을 기다려야 하나요?

아닙니다. Sume는 생성 요청에 곧바로 영수증으로 응답하지만, 롱폼 영상은 만드는 데 15분에서 30분이 걸리고, 실행은 생성 후 90분까지 이어진 뒤에야 failed로 확정될 수 있습니다. 작업(job)의 timeoutInMinutes 기본값은 60이며, Microsoft 호스팅 에이전트에서 비공개 프로젝트의 작업은 추가 용량을 구매하지 않으면 60분을 넘겨 실행할 수 없으므로, 폴링하는 작업이 먼저 취소될 수 있습니다. 기다리기를 포기해도 실행과 그 지출은 멈추지 않습니다.

예제처럼 communication.webhook_url을 보내고, 생성 요청 뒤에 작업을 끝내세요. 실행이 완료되거나 실패하면 Sume가 서명된 format.run.terminal 영수증 하나를 여러분의 서버로 POST합니다. 받는 쪽은 Sume 영상 실행용 서명된 웹훅에서 다룹니다.