젠킨스에서 태그를 골라 배포했는데 master가 나갈 때 (Git Parameter와 Branch Specifier)

젠킨스에서 태그를 선택해 배포했는데 실제로는 master 브랜치가 빌드되고 있던 원인과, 같은 문제가 깔린 잡을 한 번에 찾는 방법입니다.

배포 화면에서 태그를 골라 빌드했는데 그 태그에 들어간 수정 사항이 서버에 반영되지 않았습니다. 빌드는 성공으로 끝났고 로그에도 에러가 없었습니다.

다시 돌려봐도 결과가 같아서 설정을 열어보니, 태그를 고르는 파라미터는 있는데 정작 소스를 받아오는 자리는 master로 고정돼 있었습니다.

더 곤란한 건 그 잡 하나만의 문제가 아니었다는 점입니다. 같은 식으로 만들어진 잡을 찾아보니 운영 배포 잡에도 여러 개가 깔려 있었고, 그동안 태그를 고른 배포가 전부 master로 나가고 있었습니다.

- 태그 파라미터를 만들어도 소스를 받는 설정이 그 값을 쓰지 않으면 아무 효과가 없다

- 에러가 나지 않고, master와 태그가 같은 커밋이면 결과까지 같아서 오래 숨어 있는다

- 콘솔 로그의 Checking out Revision 한 줄로 실제 빌드한 대상을 확인할 수 있다

- 설정 파일을 검색하면 같은 문제가 있는 잡을 한 번에 찾을 수 있다

1. 파라미터는 값을 넘겨줄 뿐입니다

Git Parameter 플러그인을 쓰면 빌드할 때 태그 목록이 뜨고, 그중 하나를 고를 수 있습니다. 이걸 보고 태그 배포가 설정됐다고 생각하기 쉬운데, 이 플러그인이 하는 일은 고른 값을 TAG 같은 변수로 넘겨주는 것까지입니다.

실제로 어떤 소스를 받아올지는 소스 코드 관리 항목의 Branch Specifier(Branches to build) 가 정합니다. 여기 기본값이 */master 이고, 이걸 그대로 두면 파라미터로 무엇을 고르든 master를 받아옵니다.

변수를 만들어 놓고 그 변수를 아무 데서도 쓰지 않은 상태입니다. 화면에는 태그 선택 창이 멀쩡히 떠 있어서 설정한 사람도, 배포하는 사람도 알아채기 어렵습니다.

2. 에러 없이 오래 숨어 있는 이유

이 문제가 무서운 건 빌드도 배포도 성공해서 아무것도 실패하지 않는다는 점입니다.

게다가 대부분의 경우 결과까지 같게 나옵니다. 보통은 master에 머지한 직후 그 커밋에 태그를 달고 바로 배포하는데, 이때는 master와 태그가 같은 커밋이라 잘못 설정돼 있어도 나가는 소스가 똑같습니다.

- 태그를 단 뒤 master에 다른 커밋이 올라오면 그 커밋까지 같이 나간다

- 예전 태그로 롤백하려고 해도 최신 master가 나간다

- 반영이 안 됐다는 제보가 오기 전까지는 아무도 모른다

제 경우도 태그와 master가 어긋난 날 처음 드러났습니다. 그 전까지는 운이 좋아서 문제가 없었을 뿐이고, master에 검증 안 된 커밋이 하나만 있었어도 그대로 운영에 나갔을 구조였습니다.

3. 실제로 무엇을 빌드했는지 확인하기

의심이 들면 빌드 콘솔 로그에서 Checking out Revision 줄을 찾으면 되는데, 젠킨스가 실제로 체크아웃한 커밋 해시와, 그 커밋을 어디서 가져왔는지가 괄호 안에 나옵니다.

괄호 안에 origin/master 가 보이면 태그를 골랐어도 master를 빌드한 것입니다. 해시를 고른 태그가 가리키는 커밋과 비교하면 확실하게 가려집니다.

로그를 하나씩 열어보기 어렵다면 빌드 스크립트에서 GIT_COMMIT 변수를 찍어 두는 방법도 있습니다. 배포 기록에 태그와 커밋 해시가 같이 남도록 해두면 나중에 추적하기가 훨씬 편합니다.

4. 고치는 방법

Branch Specifier 를 파라미터 변수로 바꾸면 되는데, 파라미터 이름이 TAG 라면 ${TAG} 를 넣습니다.

- Branch Specifier 를 */master 에서 ${TAG} 로 바꾼다

- 이름이 같은 브랜치가 있어 헷갈리면 refs/tags/${TAG} 처럼 태그임을 명시한다

- 파라미터 이름과 변수 이름의 대소문자까지 맞춘다

고친 뒤에는 master와 다른 커밋을 가리키는 예전 태그로 한 번 빌드해 보는 게 좋습니다. 최신 태그로 테스트하면 master와 같은 커밋이라 고쳐졌는지 구분이 안 됩니다. 콘솔 로그의 해시가 그 태그의 커밋과 일치하면 제대로 된 것입니다.

5. 같은 문제가 있는 잡 한 번에 찾기

잡이 많으면 하나씩 열어볼 수 없으니, 젠킨스가 잡 설정을 JENKINS_HOME/jobs 아래 config.xml 로 저장한다는 점을 이용해 이 파일을 검색합니다.

찾을 조건은 두 가지입니다. Git Parameter 를 쓰는데, 소스 받는 자리는 master로 고정된 잡입니다.

여기 걸린 잡은 태그를 고르는 화면은 있는데 실제로는 master가 나가는, 1절과 같은 상태입니다.

다만 모든 결과가 잘못된 건 아닙니다. 검수 서버처럼 원래 항상 최신 master를 배포하려는 잡도 있으니, 목록을 뽑은 뒤 잡마다 의도를 확인해야 합니다. 그런 잡이라면 헷갈리지 않게 태그 파라미터를 아예 빼는 편이 낫습니다.

- 검수처럼 최신을 올리는 잡은 */master 로 두고 태그 파라미터는 없앤다

- 운영처럼 버전을 골라 올리는 잡은 반드시 ${TAG} 로 묶는다

- 두 규칙을 잡 이름이나 설명에 적어두면 다음 사람이 헷갈리지 않는다

6. 정리

태그 선택 창이 있다고 해서 태그 배포가 되는 게 아닙니다. 파라미터는 값을 넘겨줄 뿐이고, 그 값을 소스 받는 설정이 실제로 써야 의미가 있습니다.

- Git Parameter 는 변수만 만든다. Branch Specifier 가 그 변수를 써야 한다

- 기본값 */master 를 두면 무엇을 골라도 master 가 나간다

- 에러도 없고 결과가 같은 날이 많아 오래 숨어 있는다

- 확인은 콘솔 로그의 Checking out Revision 과 커밋 해시로 한다

- config.xml 검색으로 같은 문제가 있는 잡을 한 번에 찾는다

배포 하나가 안 먹힌 걸 그냥 다시 돌렸다면 이번에도 넘어갔을 겁니다. 원인을 따라가 보니 한 잡이 아니라 같은 방식으로 만든 잡 전부의 문제였고, 이런 설정은 한 번 퍼지면 복사되며 계속 늘어나니 날을 잡고 전체를 한 번 훑어보는 편이 좋습니다.

여기까지 젠킨스 태그 배포가 master로 나가는 문제에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!