이 How to configure Git post commit hookJenkins에서 한 번에 하나의 빌드 만 원격으로 트리거하는 방법은 무엇입니까?
의 확장 또는 변형 내가 가진 문제는 내가 커밋 당 하나의 빌드를하지 할 것을입니다. 대신에 한 번에 하나의 빌드 인스턴스 만 트리거하면됩니다. 단일 인스턴스가 실행되는 동안 새 요청이 누적 될 수 있지만 현재 빌드가 완료된 후에는 단일 새 빌드로 통합되어야합니다.
분명히, 트리거는 의미가있는, 일반적으로 같은 브랜치의 git 리비전에 있어야하며, 빌드는 항상 HEAD에 가장 가까운 트리거 리비전에서 실행되어야합니다 (이해가 되나요?).
그래서이 질문을 위해 모든 사람이 마스터하기를 원한다고 가정하고 빌드를 시작하기 위해 동네 훅을 배치합니다. 보류중인 요청이 별도의 빌드로 대기하는 대신 단일 요청으로 병합되도록하려면 어떻게해야합니까?
이 동작은 폴링을 사용하여 간단하게 구성 할 수 있지만 많은 관련이없는 이유로 많은 작업 (단일 작업에서 소비되는 여러 repos를 폴링해야 함)에 폴링을 사용하고 싶지 않습니다.
Jenkins parameterized job that only queues one build은 하나의 가능성을 제공합니다 : "종료 대기열 결합"으로 신속하게 종료되고 실제 작업을 시작하는 "런처"작업을 사용하십시오. 이 접근법의 문제점은 런처 작업이 작업 작업을 시작하기 전에 저장소를 체크 아웃해야한다는 것입니다. 주어진 git repo가 크면 수용 할 수없는 지연이 발생합니다.
나에게 일어난 한 가지 생각은 작업이 대기열에 누적되도록 허용하고 작업이 실행될 때마다 실행을 트리거하는 git commit을 무시하고 HEAD를 체크 아웃 한 다음 작은 시스템을 멋지게 실행합니다. 스크립트는 작업 시작 시간보다 오래된 모든 큐를 지우는 스크립트로, 빌드를 시작한 후에 들어 왔지만 큐에서 스크립트를 실행하기 전에 새로운 요청을 남기므로 실행을 놓치지 않습니다. 새로운 요청이 더 이상 들어오지 않습니다 ... –
대기열 정리 문제는 새로운 실행이 트리거 될 때까지 수백 개의 새로운 요청이 쌓일 수 있기 때문에 왼쪽의 작업 기록을 거의 쓸모 없게 만듭니다. –
또 다른 아이디어는 장시간 실행되는 싱글 톤 작업을 직접 트리거하지 않고 장기간 실행되는 작업의 큐를 차례로 관리하는 작은 시스템 그루비 작업을 트리거하는 것입니다. 모든 호출에서 실제 작업이 실행 중인지 확인하고 그렇지 않으면 실행하십시오. 대기열이 비어 있으면 대기열에 넣고, 그렇지 않으면 대기열을 비우고 새 작업을 대기열에 넣습니다. –