일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 다이나믹프로그래밍
- search api
- 페이징
- event_scheduler
- 2375
- WebFlux
- 자바
- DP
- jenkins
- 젠킨스
- bitbucket
- 백준
- 도커
- MariaDB
- while
- 검색 API
- Programming
- 빗버킷
- 알고리즘다지기프로젝트
- 알고리즘
- 스프링 번역
- 컴퓨터공학기초
- RESTful
- 11053
- Reactive stream
- Today
- Total
목록젠킨스 (2)
쑥로그
이 설정을 하면서 가장 어려웠던 점은 서브 프로젝트들이 한 레파지토리에 있었기 때문에 1. 빗버킷 커밋을 하면 모든 서브 프로젝트들이 한 푸쉬를 받는 다는 것 2. 한 레파지토리를 서브 프로젝트 아이템들이 전부 받게 된다는 것(불필요하게) 였다. 기존 소스가 그렇게 되어있기도 해서 레파지토리를 따로 파야하나 싶었다. 각 서브 프로젝트별로 나누려고 하다보니 공통 모듈들이 또 각 서브프로젝트 레파지토리에 전부 들어가게 생겼다. 이걸 또 빼서 의존성을 주자니 기존 소스를 많이 안건드리고 싶었다. 그래서 젠킨스에서 어떻게든 해주지 않을까 하고 폭풍 검색했다. 결론은.. 있었다!!! 1. 소스 코드 관리에서 Sparse Checkout paths로 2번 문제를 해결한다. 이렇게 하면 path에 적은 디렉토리 혹은..
기존에는 깃랩에 커밋하면 젠킨스가 빌드&배포하게 되어있는 흐름이었고, 다른 분께서 직접 구축까지 해놓으셨는데, 이번에 빗버킷을 쓰게 되면서 직접 구축을 해야하는 상황이 되었다. 빗버킷에 대한 이해와, 젠킨스와의 연동, 도커파일 실행과 배포까지 꼬박 4일이 걸렸다. 연동은 금방 끝났는데 도커가 의외의 복병이었다. 도커파일이 동작은 하는데 이미지가 원하는 데로 만들어지지 않아서 정말 애를 많이 먹었다. 목표 : 빗버킷에 소스 커밋 -> 젠킨스 실행 -> 도커 이미지 빌드 -> 도커허브에 푸쉬 과정 1. 빗버킷에서 소스파일 커밋 감지와 웹훅 빗버킷의 Repository settings > Post Webhooks 에서 웹 훅을 생성한다. 1. title은 임의로 설정한다. 2. URL은 본인의 젠킨스 url ..