<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gradle on 얼쑤 · Team Edo</title><link>https://team-edo.github.io/tags/gradle/</link><description>Recent content in Gradle on 얼쑤 · Team Edo</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Fri, 06 Nov 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://team-edo.github.io/tags/gradle/index.xml" rel="self" type="application/rss+xml"/><item><title>테스트한 JAR을 이미지에 그대로 넣기</title><link>https://team-edo.github.io/posts/2026/11/reuse-verified-jar-in-image/</link><pubDate>Fri, 06 Nov 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/11/reuse-verified-jar-in-image/</guid><description>&lt;p>얼쑤의 백엔드 CI는 Jenkins에서 Gradle로 검사하고 실행 JAR을 만든 뒤, Docker로 배포 후보 이미지를 빌드했습니다. 오래 걸린 빌드의 로그를 보니 Dockerfile이 소스와 Gradle Wrapper를 받아 &lt;code>bootJar&lt;/code>를 한 번 더 실행하고 있었습니다. Docker 레이어 캐시가 적중하지 않은 한 실행에서 이미지 안의 재빌드만 1분 51초가 걸렸습니다.&lt;/p>
&lt;h2 id="실행할-jar을-먼저-확정했다">실행할 JAR 먼저 확정&lt;/h2>
&lt;p>배포 후보 이미지의 역할을 확인해 보니, 배포 도구는 후보를 띄워 확인한 뒤 그 안에서 JAR을 꺼내 운영 실행 이미지에 연결하고 있었습니다. 후보 안에서 JAR을 다시 만들어야 할 이유가 없어, Jenkins가 이미 검증한 실행 JAR을 이미지에 넣도록 바꿨습니다.&lt;/p></description></item><item><title>Jenkins Wasm 최적화 956초에서 237초로</title><link>https://team-edo.github.io/posts/2026/11/jenkins-wasm-build-bottleneck/</link><pubDate>Wed, 04 Nov 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/11/jenkins-wasm-build-bottleneck/</guid><description>&lt;p>얼쑤의 Jenkins 빌드가 길어졌을 때, 저는 완료 화면의 전체 시간부터 단계별로 쪼개 봤습니다. 백엔드 빌드에서는 시작 기록이 남은 뒤 첫 단계까지 14분 넘게 걸렸고, 별도의 웹 빌드에서는 실제로 실행기에 올라간 뒤 Wasm 최적화 도중 시간 제한에 걸렸습니다. 두 경우 모두 빌드가 오래 걸렸지만, 손봐야 할 곳은 달랐습니다.&lt;/p>
&lt;h2 id="첫-단계가-시작되기까지-얼마나-걸렸나">첫 단계까지의 대기 시간&lt;/h2>
&lt;p>빌드 기록의 시작·종료 시각을 Jenkins의 단계별 시작·종료 시각과 맞춰 봤습니다. 빌드 시작부터 첫 단계까지, 첫 단계부터 마지막 단계가 끝날 때까지, 마지막 단계 이후로 나누면 어느 구간이 길었는지 보입니다.&lt;/p></description></item></channel></rss>