2013-02-18 2 views
3

수은 설치에서는 지속적인 통합 스크립트를 기반으로 특정 빌드에 자동으로 태그를 지정하고 싶습니다. 예를 들어, 분기 빌드가 배포 될 때마다 branchName-buildId과 같은 태그 또는 빌드가 모든 통합 테스트를 통과 할 때마다 latest-stable 일 수 있습니다.Mercurial : 자동으로 빌드에 태그 달기

그러나, 나는 단순히 hg tag를 호출하는 간단한 방법은 문제를 일으킬 수 있다는 걱정 :

  • 일부 태그는 중복 될 수있다 - 즉 latest-stable합니다. 이 상황에서 어떤 빌드가 태그 지정되는지는별로 신경 쓰지 않지만 스크립트가 이러한 빌드를 해결할 수 없기 때문에 어떤 충돌도 원하지 않습니다.
  • 태그가 커밋됩니다. 그러나 이것은 커밋을 푸시 할 필요가 있다는 것을 의미하며 동시에 인간이나 다른 스크립트에 의한 동시성에도 불구하고 강력해야합니다. 특히, 자동 푸시는 추가 헤드를 생성 할 수 있으며 이는 좋지 않습니다. 그러나 추가 헤드가 감지되면 (밀어 넣기시) 이미 로컬 태그 커밋이 발생하고 새로운 헤드가 쉽게 병합 될 가능성이 있더라도 태그가 충돌을 일으키는 경우가 있습니다.

어떻게 자동으로 CI 서버가 빌드 태그에 안정적으로 태그를 지정할 수 있습니까? 여기서 최종 결과가 일관성있게 유지되는 것이 더 중요합니다 (즉, CI 서버 또는 저장소를 엉망으로 만들지 않음). 중복 또는 충돌에 대해 태그를 안정적으로 적용하는 것이 덜 중요합니다 (이는 어쨌든 매우 어려울 것입니다).).

답변

1

나는 신중해야한다고 생각합니다. 로봇은 항상 최고의 시민은 아니며 종종 바보 같은 짓을 할 수 있습니다.

최종 결과물은 사용중인 태그의 내용에 따라 다릅니다. 예를 들어, CI 시스템을 사용하는 CI 시스템 만 볼 수 있다면 로컬로 유지하는 것이 좋습니다. 끌어 오기/밀어 넣기/병합 문제가 전혀 없습니다.

일부 태그는 중복 될 수 있습니다. 즉 최신 안정성이 있습니다. 이 상황에서 어떤 빌드가 태그 지정되는지는별로 신경 쓰지 않지만 스크립트가 이러한 빌드를 해결할 수 없기 때문에 어떤 충돌도 원하지 않습니다. 태그가 이미 정의, 그리고 다시 hg tag를 호출하는 경우

, 그것은 당신이 그것을 강제하지 않는 한 실패,하지만이 일은 동일한 태그의 새로운 나중에 정의하고, 최신의 승리를 추가 할 것입니다 것입니다. (

hg update -r latest-stable 
hg update -r latest-stable 
hg update -r latest-stable 
hg update -r latest-stable 

태그가되었다 전에 버전을 얻을 것이다 당신이 버전으로 업데이트합니다 때마다 : 병합은 간단하지만, 당신이 할 때 사건에 대해 생각하기 때문에 한편으로이 좋다 정상적으로), 해당 버전 latest-stable은 이전 latest-stable을 가리 킵니다. 결과적으로이 명령 시퀀스가 ​​시간을 거슬러 올라갈 것입니다.

따라서 고유 한 태그 (예 : stable-2013-02-18) 또는 두 개의 커밋에 태그를 추가하는 것이 좋습니다. 하나는 이전 태그를 제거하고 하나는 새 태그를 추가하는 태그입니다.

hg update -r latest-stable # You're now at the commit that removed the tag. 
hg update -r latest-stable # This one will error because tag doesn't exist 

태그 원인은 커밋합니다. 그러나 이것은 커밋을 푸시 할 필요가 있다는 것을 의미하며 동시에 인간이나 다른 스크립트에 의한 동시성에도 불구하고 강력해야합니다. 특히, 자동 푸시는 추가 헤드를 생성 할 수 있으며 이는 좋지 않습니다. 그러나 추가 헤드가 감지되면 (밀어 넣기시) 이미 로컬 태그 커밋이 발생하고 새로운 헤드가 쉽게 병합 될 가능성이 있더라도 태그가 충돌을 일으키는 경우가 있습니다.

CI 로봇은 tag; pull; merge (if necessary); push이어야합니다. 병합에 실패하면 밀어 넣지 말고 경보를 울리십시오. 푸시가 실패한 경우 (즉, 병합에 걸린 시간에 더 많은 변경 집합이 있음) 다시 당겨서 병합합니다. 나는 당신의 스크립트가 그것이 병합하고있는 개정판에 대해 매우 명시 적인지를 확실히 할 것이다. 이 과정은 여분의 머리없이 당신을 떠나야합니다.

머큐리얼은 내용을 알고 있기 때문에 머큐리얼이 .hgtags 파일을 다르게 취급하므로 충돌이 매우 드뭅니다. 또한 변경 사항이 모두 .hgtags이므로 태그 커밋은 일반적으로 병합이 쉽기 때문에 CI 헤드의 병합이 충돌하지 않아야합니다. 다른 사람이 CI 서버와 동일한 태그 이름을 사용하고 있기 때문에 그럴 수있는 유일한 이유는 키보드를 붓고 있어야만 더 이상 손상을 입힐 수 있기 때문입니다.

동일한 태그 이름을 사용하여 여러 헤드에서 태그 지정을하는 경우 문제가 발생할 수 있습니다. 예 : 개발 및 릴리스 지점 모두에서 CI가 실행되며 두 가지 모두 tests-clean 태그가 지정되었지만 다른 개정판에 할당 된 후 나중에 병합됩니다. 해결책은, 그러지 마라.

그 중 일부가 도움이 되길 바랍니다.

+0

많은 빌드를 병렬로 실행하므로 CI 리포지토리를 로컬로 유지할 수 없습니다. 즉 많은 CI 리포지토리가 있습니다. 나는 중간의 "버퍼"repo를 가질 수 있다고 생각하지만 푸시/풀 스토리를 훨씬 더 복잡하게 만듭니다 (예 : 여전히 서로간에 병합해야 함). 또한 devs가 어떤 changesets가 살고 있는지보기는 꽤 좋은 일입니다. 인프라 스트럭처를 실행하기 위해 모든 노력을 기울이는 것은 수치 스럽습니다. 그리고 모든 것이 수은에 있지만 마지막 마일을 가지지 않고 실제로이 정보를 전달하는 것은 부끄러운 일입니다. –

+0

'hg update latest-stable'로 가면, mercurial은 * working copy * 태그를 보지 않고 모든 헤드 태그의 조합을 보게됩니다. 따라서 반복적 인'hg update latest-stable' 명령에는 아무런 문제가 없습니다. –

+0

병합과 관련하여 : .hgtags는 단지 추가 태그이며, 이것은 모든 태그 변경 충돌을 의미합니다 - 단지 동일한 태그를 변경하는 것만이 아닙니다! 따라서 다양한 CI 빌더가 서로 충돌합니다. 다른 사람이 충돌하는 비 관련 태그를 추가하는 경우 본질적으로 이것이 의미하는 바는 간단한 자동 업데이트가 작동하려면 각 태그 편집이 직렬화 가능하고 원자 적으로 전체적으로 * 필요하다는 것입니다. –

0

빌드 기록에 신경 쓰면 빌드 프로세스 용으로 명명 된 분기를 만드는 것이 좋습니다. Mercurial에서는 모든 지점의 모든 태그가 전체 저장소에 표시됩니다.

내역에 대해 신경 쓰지 않는다면 bookmarks 트릭을해야합니다. 빌드 프로세스는 테스트가 실행 된 후에 북마크 latest-stable을 설정 한 다음 hg push --bookmark latest-stable을 실행하여 해당 북마크를 서버로 푸시 할 수 있습니다.

어느 쪽이든 이미 테스트를 마친 수정본에 대한 테스트를 실행하지 않도록주의해야합니다. Mercurial revsets은 매우 강력한 쿼리 언어이며 도움이됩니다.

+0

그래, 북마크를 보았는데, 그들은 기본적으로 활성화되어 있다는 사실을 제외하고는 매우 매력적이었다. 예를 들어'latest-stable'로 업데이트하고 커밋을하면 암묵적으로 책갈피를 옮겼습니다! 그건 좋지 않다. 그 동작을 비활성화하는 방법을 찾을 수 없습니다 (매번 명시 적으로 비활성화하고 모든 개발자가 그렇게하도록 설득하는 것 외에는 장기적으로 잘 작동하지 않을 수 있습니다). –

+0

이미 빌드 프로세스의 명명 된 분기가 있으므로 CI 서버가 배포 할 대상과 방법 (예 : 어디서 테스트 할 것인지)을 알 수있는 방법입니다. 하지만 배포에 대한 최종 선택은 사람이므로 해당 지점의 모든 변경 집합이 배포를 유발하지 않으며 수동 유효성 검사를 통과하는 변경 집합 만 표시되는 것은 아닙니다. * 태그 지정 (또는 책갈피 지정 등). –

관련 문제