2016-09-14 5 views
0

나는 더 큰 프로젝트 (파이프 라인)의 일부인 많은 프로젝트에서 작업하고 있으므로 함께 테스트해야합니다. 수동 테스트는 그다지 훌륭하지 않기 때문에 앞으로 Gradle + Jenkins CI를 사용하여 테스트를 진행하기로 결정했습니다. 첫 번째 테스트는 successfuly 였고, 유닛 테스트 등은 훌륭하게 실행되었고 Jenkins는 JAR 파일을 빌드합니다.Gradle/Jenkins JAR GitHub로 출시

모든 프로젝트가 오픈 소스이며 GitHub에서 사용 가능하므로 각 프로젝트의 GitHub 릴리스 페이지에 게시되도록 설정하고 싶습니다. 이 같은 :

내가 개발
  • ,
  • 젠킨스는 후크를 통해이 문제를보고 힘내 태그로 커밋, 물건을 구축 할 수있는 Gradle을 스크립트를 실행하고 성공적인 테스트에 새로운 내 프로젝트에서 생성 된 JAR 파일을 게시 GitHub의 출시 버전

불행히도, 이것은 예상대로 작동하지 않습니다. 예를 들어 Plugin here을 사용하면 JAR 파일이 아닌 패키지 소스 코드 만 푸시됩니다. 그렇지 않으면 이것은 잘 작동하고 나는 방금 무언가를 감시했을 것입니다?

누군가이 경험이 있습니까?

+1

생성 된 JAR 파일을 코드와 함께 Git 저장소로 푸시해야하는 이유는 무엇입니까? Git repo에서 jar와 같은 무거운 파일을 푸는 것은 좋지 않습니다. 대신 [Artifactory]와 같은 저장소 관리자 (https://www.jfrog.com/open-ko)에서 다른 위치로 보내야합니다. source /) ... – Pom12

+0

안녕하세요 Pom12 - 내 첫 코멘트가 충분히 구체적이지 않다고 생각합니다. 내 내장 JAR 파일을 내 저장소 자체에 커밋하고 싶지는 않지만 예를 들어 GitHub에서 내 프로젝트의 "릴리스"섹션을 사용하여 최종 사용자의 JAR 파일을 릴리스하십시오. 물론 예를 들어 Bintray에 의존 할 수는 있지만 최종 사용자에게 더 나은 가시성을 제공하기 위해 내 빌드 된 JAR을 특정 프로젝트 릴리스 섹션으로 푸시하려고합니다. – w3b1x

답변

0

Github release이 무엇인지 착각하고 있다고 생각합니다. Github 관점에서 볼 때 릴리즈는 arfifact (예 : 빌드 된 Jar)를 배포 할 폴더가 아니지만 기본적으로 특정 커밋을 가리키는 Git 태그이며 "ok,이 커밋 d215465454는 내 릴리스 1.2.3 ". 커밋을 가리키는 포인터 일 뿐이므로 특정 "릴리스"에 대한 Git 히스토리를 항상 찾을 수 있습니다. 자세한 내용은 Git excellent Tagging documentation을 참조하십시오.

또한 실제 항아리를 최종 사용자에게 노출 시켜서는 안됩니다. 대신 Bintray 또는 Artifactory를 사용하여 실제 jar 이슈를 배포하고 최종 사용자가 자신의 jar 파일에 따라 gradle 빌드 파일을 구성 할 수 있습니다.