지금 빌드 서버로 HUDSON을 쓰고 있다.
상당히 오랜동안 쓰다 보니 나름 익숙해진 부분도 많아서 지금은 계속 HUDSON을 사용하고 있다.
그런데, 문제는 이 HUDSON에서 플러그인으로 제공하는 SVN 이 버전 문제를 앓고 있다는 점이다.
체크인을 해서 분명 SVN내 버전이 올라갔는데도 불구하고, HUDSON에서 새버전에 따른 트리거를 발동하여 자동 빌드가 들어가지지 않고, 계속 대기를 타고 있었다.
처음에는 HUDSON 자체의 문제로 인지하고, 각종 업데이트를 했지만, 요지 부동!.
결국 찾아낸 것이 폴링에 대한 실행 결과를 보니 나오는 문제가 있었다.특히 SVN서버가 1.8 버전 일때, 다음과 같은 형태의 오류가 폴링 오류로 잡히게 된다.
(현재 HDUSON은 정상 작동하여 Polling 오류 메시지를 찾을 수 없어, 대신 Jenkis에서 발생된 예제를 띄웁니다. 약간 오류의 메시지가 다르게 나타나지만, 유사한 오류 입니다.)
Received SCM poll call on for NGCS on Oct 21, 2013 11:26:09 AM
ERROR: Failed to check repository revision for [..]/trunk
org.tmatesoft.svn.core.SVNException: svn: E210004: Number is larger than maximum
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:400)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:456)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readTuple(SVNReader.java:288)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.parse(SVNReader.java:241)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.read(SVNConnection.java:272)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.read(SVNRepositoryImpl.java:1290)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.info(SVNRepositoryImpl.java:1203)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:65)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2461)
at hudson.scm.SubversionSCM.parseSvnInfo(SubversionSCM.java:1122)
at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:71)
at hudson.scm.CompareAgainstBaselineCallable.call(CompareAgainstBaselineCallable.java:26)
at hudson.remoting.LocalChannel.call(LocalChannel.java:45)
at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1278)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject._poll(AbstractProject.java:1567)
at hudson.model.AbstractProject.poll(AbstractProject.java:1490)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:439)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:468)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: svn: E210004: Number is larger than maximum
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.readItem(SVNReader.java:399)
... 33 more
Done. Took 0.1 sec
No changes
문제 원인
이 문제는 HDUSON의 문제가 아닌 HUDSON의 SVN 플러그인의 문제이다.
플러그인이 애석하게도 SvnKit 1.7 기반으로 만들어져 있어서, SVN의 서버가 1.8 이상인 경우 버전 정보만 가져올 때 잘못된 값을 가져와서 발생된 문제이다. 물론 직접 디버깅을 걸어 확인한 사항은 아니지만, 최소한 위의 Exception 정보 및 해당 내용을 Google로 검색해보면 대략 답이 나온다.
결국 SVN 플러그인을 업그레이드 하던가, 1.7로 낮추던가 둘중 하나를 택해야 한다.
하지만 현재(2014년 3월 10일)까지 SVN 플러그인은 여전히 1.7까지만 지원하고, 아직도 업그레이드가 안되고 있다.
결국 내가 가진 SVN 서버의 버전을 낮추는 방법 밖에는 없다.
SVN 1.7 버전 다운로드.
현재 SVN 서버는 Windows에서 실행하고 있다. Bitnami의 Redmine 스택을 설치하면 Subversion 폴더가 있는데, 그안의 내용을 일부 수정해서 독자적으로 서비스로 등록해 사용 중이다. 그런데, 최신 스택이다 보니, 이 Subversion도 무려 1.8.5 버전.
현재 이 버전으로 돌리니 당연히 HUDSON이 지원안되는 것이였다.
그래서 이 서버 파일들을 모조리 1.7용으로 바꿔야 한다.
SVN 실행 파일들을 획득하는 방법은 다양하게 있지만, 필자는 CollabNet에서 다운 받았다. ( http://www.collab.net/downloads/subversion ) 물론 사이트 Front에 들어가면 1.8 부터 노출되어 있으니, 패스.
맨 아래쪽에서 제공하는 링크인 http://www.collab.net/downloads/svn-other 로 이동해서, 1.7.16 버전을 다운 받았다. 당연히 x64 서버이니, x64 버전을 다운 받았다.
받은 파일을 실행해서 적당한 Folder에 설치했다.( D:\svn ). 그 안에 보면 각종 dll과 실행 파일들이 있는데, 바로 이 파일들이 1.7용 SVN이 된다.
버전 이력 마이그레이션
먼저 SVN 서비스를 돌리고 있다면 먼저 중지시킨다. 로컬이라면 SVN을 접근하는 프로그램들을 모두 중지시키도록 하자. 그리고 난 뒤, 실행 파일을 덮어쓰기 위한 준비작업을 실행한다. 그냥 실행파일만 바꾸게 되면, SVN 저장소의 DB 포멧이 달려저서 자칫 SVN DB가 망가지거나, Client에서 접근이 어렵다. 먼저 SVN을 백업 하도록 한다.
svnadmin dump [subversion DB 파일들이 있는 경로] > backup.bak
이 처럼 해서 먼저 모든 버전들 백업을 확보한다.
백업이 완료되었으면 이전 DB는 삭제한다.
이제 다운로드 받은 1.7 버전을 덮어써준다.
다시 1.7 버전의 svnadmin으로 DB를 생성한다.
svnadmin create [subversion DB 경로]
마지막으로 백업 받은 내용을 DB에 부어주도록 한다.
svnadmin load [subversion DB 경로] < backup.bak
이제 중지 시켰던 서비스를 다시 실행한다.
정리
요즘은 Hudson 대신 Jenkis를 주로 쓰는 추세인지, HDUSON 자료를 찾다보면 Jenkis가 훨씬 많은 레퍼런스를 보여준다. 하지만, Jenkis 자체의 태생이 HUDSON이여서 인지, 실제 구성하는 방법은 50보 100보.
여튼 이번에 SVN 이슈 때문에, 빌드는 계속 밀렸었고, 당황했는데, 간신히 살린 것 같다.
이번에 좀 뻘짓하면서 개발 환경 재정리하면서 빌드서버 까지 정리 완료 했으니, 그간 미룬 작업들 까지 모조리 정리해야 겠다. 나중에 뻘짓 안하기 위해 귀찮더라도 기록을 남긴다.