クイズ: 順序・条件・受け渡し

잡에 needs: [] 를 적은 것과 needs 키를 아예 적지 않은 것의 차이는?

• 빈 목록은 아무것도 기다리지 않고 키가 없으면 앞 스테이지 전부를 기다린다
• 빈 목록은 앞 스테이지 전부를 기다리고 키가 없으면 즉시 출발한다
• 둘 다 앞 스테이지가 끝나기를 기다리며 표기만 다른 같은 설정이다
• 빈 목록은 설정 오류라 파이프라인이 아예 만들어지지 않는다

잡을 전부 DAG 로 묶은 파이프라인에서 러너를 아무리 늘려도 줄지 않는 시간은?

• 가장 오래 걸리는 잡 하나의 실행 시간
• 잡 개수를 러너 수로 나눈 평균 대기 시간
• 웨이브를 순서대로 이은 가장 긴 경로의 시간
• 스테이지 개수에 잡 개수를 곱한 시간

rules 목록 가운데에 조건 없는 when: never 항목을 두면?

• 조건 없는 항목은 무시되고 나머지 규칙이 정상 평가된다
• 그 항목이 항상 걸려서 아래에 적은 규칙은 영영 읽히지 않는다
• 목록 전체가 무효가 되어 잡이 항상 실행된다
• 설정 검증 단계에서 오류로 걸려 파이프라인이 거부된다

운영 배포 잡을 when: manual 로 두었는데 아무도 누르지 않은 파이프라인이 성공으로 끝났다. 원인은?

• needs 를 적지 않아 잡이 앞 스테이지와 함께 건너뛰어졌다
• rules 가 파이프라인 생성 시점이 아니라 잡 시작 시점에 평가됐다
• stage 이름이 stages 목록에 없어 잡이 목록에서 빠졌다
• allow_failure 가 true 라 누르지 않아도 파이프라인이 성공 처리된다

artifacts 와 cache 의 차이를 가장 정확히 짚은 것은?

• 아티팩트는 없으면 뒤 잡이 실패해야 맞고 캐시는 없어도 잡이 그냥 돌아야 맞다
• 아티팩트는 러너 안에만 남고 캐시는 서버에 올라가 오래 보관된다
• 아티팩트는 압축되지 않고 캐시는 압축되어 전송량이 줄어든다
• 아티팩트는 같은 잡에서만 쓰이고 캐시는 다른 잡으로 건너간다

캐시 키를 고정 문자열 대신 key: {files: [requirements.txt]} 로 두는 이유는?

• 키 이름이 길어져 다른 프로젝트와 충돌할 확률이 줄기 때문
• 캐시 저장 공간의 한도가 파일 개수만큼 늘어나기 때문
• 의존성이 바뀌면 키가 저절로 달라져 캐시가 자동으로 무효화되기 때문
• 잠금 파일을 커밋하지 않아도 캐시가 동작하게 되기 때문