다음 그림과 같이 내가 특정 branch를 push했을때 github에서 이를 인지하여 jenkins로 webhook을 날리고 tomcat서버로 배포하는 과정을 자동화 해봤다. 일단, 새로운 아이템 > Freestyle project를 클릭한다. Github Project를 체크하고 Github 프로젝트의 주소를 입력한다. 소스코드 관리에서는 Git을 체크하고 Repository url과 아이디/비밀번호 정보를 담은 Credentials를 입력한다. 빌드유발에서는 GitHub hook trigger for GITScm polling을 클릭한다. 웹훅 설정은 Github 저장소에 들어가서 아래와 같이 수행한다. Settings > Webhooks > Add webhook을 클릭한다. Payload URL에..
다음과 같은 에러가 발생하였다. jenkins Couldn't find any revision to build. Verify the repository and branch configuration for this job. 무슨 일이지... 로그를 확인해보니 branch를 찾을수 없다는 이야기인것 같다. 원인은,, 최근 github브랜치의 경우 master가 아닌 main이 주 브랜치로 쓰이는 것 같다.. 하핳.. */master -> */main으로 바꿔주니 에러는 해결되었다.
최근 우리팀의 코드는 모두 TDD로 작성되고 있다. TDD.. 뭔가 말로는 쉬워보였지만 막상 짜려니 손이 가지 않는다. 특히 Elasticsearch같은 다른 어플리케이션에 종속된 코드를 짤 때에는 특히 더 그렇다. Kafka테스트의 경우 EmbeddedKafka를 이용하여 테스트를 진행하였는데, ES도 EmbeddedElasticsearch를 제공하지 않을까 하는 마음에 설레하며 찾아보았지만, 다음과 같은 답변을 볼 수 있었다.(https://discuss.elastic.co/t/in-memory-testing-with-resthighlevelclient/106196/5) 요약하자면, EmbeddedElasticsearch를 이전에는 제공하였지만, 이제 이 기능이 Deprecated되었고, 다른 것을 ..
회사에서 프로젝트를 하는 도중 카프카의 특정 토픽이 비어있는지 확인하는 메서드를 찾아봤는데, 팀원분께서 작성한 코드를 활용하니 특정 토픽이 비어있는지 확인할 수 있었다. AdminClient 클래스를 이용하면 작동중인 Consumer나 Producer의 작업에 영향을 미치지 않고 해당 정보를 얻을 수 있는데, 이에대해 코드를 좀 더 다듬어 포스팅 한다. package com.example; import org.apache.kafka.clients.admin.*; import org.apache.kafka.clients.consumer.OffsetAndMetadata; import org.apache.kafka.clients.producer.ProducerConfig; import org.apache.ka..
최근 Kafka를 공부하고 있는데, 윈도우에서 리눅스 명령어를 사용하기 위해 WSL을 설치하고 WSL상에서 명령어를 입력하니 자바가 설치되어 있지 않다고 나온다. 윈도우 상에서 자바 환경설정을 했더라도, WSL을 사용하면서 자바를 사용하려면 자바를 따로 설치해야 하는 것으로 보인다. 설치 방법은 다음과 같다. $ sudo apt-get update $ apt-get install openjdk-8-jdk위의 두 명령어를 실행하면 설치가 완료되는 것을 확인할 수 있따.
에버노트와 구글 캘린더를 연동하는데 성공은 하였지만, 매번 브라우저를 켜서 구글 캘린더를 켜는 작업조차 귀찮다는 생각이 들었다. 그래서 맥 캘린더와 연동할 수 있는 방법에 대해 알아보고 이에대해 포스팅하고자 한다. 맥 캘린더를 켜고 좌측상단 > 캘린더 > 계정을 클릭한다. 위와같은 화면이 나오는데, 여기서 Google을 클릭한다. 자신의 Google아이디를 입력한후 다음 버튼을 눌러 인증을 시도한다. 인증후 얼마간의 시간이 지나면 다음과같이 구글 캘린더의 자료와 연동되는 것을 확인할 수 있다.
아침에 잠이 안와서 유튜브에서 인텔리제이 꿀팁을 보던 도중 조건에 맞을때만 브레이크 포인트에 걸리게 하는 기능에 대해서 알게 되었다. 가령 다음과 같이 10번의 루프를 도는 for문이 있다고 할때 매번 브레이크 포인트가 걸리는 것이 아니라 내가 원하는 조건에 맞는 경우에만 브레이크 포인트가 걸리게 할 수 있다. public class Main { public static void main(String[] args) { for (int i = 0; i < 10; i ++) { System.out.println(i); } } } 왼쪽에 브레이크 포인트를 만들고 우클릭을 하면 아래와 같은 화면이 뜨는데, Condition 입력란에 boolean값을 입력하면 조건에 맞을때 브레이크포인트에 멈춰선다고 한다.
이런저런 고생끝에 build가 수행되도록 하였다. 그런데 곰곰히 생각해보니, ec2로 배포하는 로직같은것은 추가하지 않았는데, build의 결과가 나왔는지, 어디로 갔는지 궁금하였다. 빌드의 결과는 빌드를 수행한 작업 item을 누르고 좌측의 작업공간을 누른다. 그리고 build>libs로 들어갔다. 위와같이 jar파일이 생성된 것을 확인할 수 있었다. 아마 이 데이터를 원격 저장소로 push?하고 jar를 실행시키는 스크립트를 따로 만들어야 배포구성이 완료되는것이 아닐까 싶다.
tools.jar를 찾을수 없다는 메시지가 나오고 있다. JDK가 아닌 JRE를 사용하고 있기 떄문에 tools.jar를 못찾는 증상을 보인다. 그렇기 때문에 젠킨스 설정에서 JDK를 추가하도록 한다. 젠킨스 화면 좌측에서 Jenkins관리 버튼을 누른다. Global Tool Configuration 을 누른다. JDK installations에서 ADD JDK를 누른후, JDK이름, Version을 서정한 후, Delete Installer 버튼을 누르고 확인을 누른다. 정상적으로 빌드되는걸 확인하였다.
Webhook 설정을 완료하고나서 build를 수행하였는데 다음과 같은 에러가 발생하였다. ./gradlew: Permission denied gradlew에 대한 권한이 없는 것으로 보였다. 그래서 다음의 스크립트를 스크립트에 추가하였다. chmod +x gradlew 위의 설정을 추가함으로써, gradlew를 수행하는데 이상이 없음을 확인할 수 있었다.