이 Docker 기반 개발 환경은 Jenkins 경고 및 범위 플러그인의 새로운 기고자가 초기 램프 업 시간을 줄이기위한 것입니다. 다음 부분으로 구성됩니다.
2022 년 1 월에 기록 된 Jenkins Online Meetup 에서이 개발 환경을 발표했습니다.
개발 환경은 MacOS, Ubuntu Linux (MacOS에서 실행되는 가상 시스템) 및 Windows에서 테스트되었습니다. 풀 요청은 항상 환영합니다.
다음 도구의 최신 버전 :
또한 다음 도구의 최신 버전이 필요합니다.
오류가 발생하면 아래의 문제 해결 힌트에 유의하십시오. Windows 사용자의 경우 : Git Bash를 사용하여 쉘 스크립트를 실행하십시오.
./bin/clone-repos-https.sh ( ./bin/clone-repos.sh Github에서 SSH 키를 이미 설정 한 경우). Intellij를 열기 전에 빌드가 성공할 때까지 기다려야합니다. 그렇지 않으면 Intellij는 생성 된 모든 클래스를 찾지 못합니다. Maven 사용자는 Maven Central에서 모든 종속성이 다운로드 될 때까지 몇 분 동안 기다려야합니다.warnings-ng-plugin-devenv 선택하십시오./bin/jenkins.sh 로 Jenkins를 시작하십시오. 이 명령은 Jenkins Docker Image를 빌드하고 등록 된 모든 플러그인을 다운로드하고 Jenkins Workspace를 일부 작업으로 초기화합니다. 이것은 몇 분이 필요합니다 (9 단계 참조). 모든 다운로드가 성공했지만 오류로 인해 설치가 실패한 경우, 설치 만 재 시도하기 위해 mvn -V -U -e install –DskipTests 실행하십시오.
오류가 "명령 줄이 너무 길다"는 경우. 다음 단계를 실행합니다.
@argfile (Java9+) 선택하십시오.Jenkins 테스트 시간 초과로 인해 테스트가 실패하면 다음 단계를 실행하십시오.
-Djenkins.test.timeout=1000 . 이렇게하면 시간 초과 한계가 1000 초로 증가합니다. 간단한 쉘 스크립트 ( ./bin/clone-repos.sh )를 사용하여 한 단계로 모듈을 복제하고 빌드 할 수 있습니다. 스크립트는 GIT SSH 프로토콜을 사용하여 다음 모듈을 확인합니다. 이를 위해서는 Github에 공개 키를 등록해야합니다. GitHub에 키가 없으면 HTTPS 프로토콜을 사용하는 스크립트 ./bin/clone-repos-https.sh 를 사용할 수 있습니다.
플러그인 중 하나에 대한 풀 요청을 제공 할 때 리포지토리의 포크를 만들고이 포크를 변경해야합니다. 코딩 스타일 프로젝트에서 Github 공동 작업 문서를 만들었습니다.
Intellij (Ultimate)는 경고 플러그인의 주요 지원 개발 환경입니다. 사전 정의 된 프로젝트는 경고 플러그인의 모든 모듈을 참조하는 폴더 .idea 에 저장됩니다. 이 프로젝트에는 코딩 스타일의 사전 설정과 다른 유용한 구성이 포함되어 있습니다.
다른 IDE (Eclipse, NetBeans, Visual Studio Code)를 사용할 수 있어야합니다.
제공된 Intellij 실행 구성을 All in [module-name] 사용하여 해당 모듈의 장치를 실행하고 통합 테스트를 실행하십시오. 이러한 구성은 이미 해당 모듈 패키지의 분기 범위를 기록하도록 구성되어 있습니다 ( Run with Coverage 사용하십시오).
변경 사항을 디버깅하기 전에 먼저 코드가 실행중인 위치를 찾아야합니다 : 컨트롤러 또는 에이전트에서? 확실하지 않은 경우 원격 디버거를 모두 실행하고 중단 점을 설정 한 다음 해당 디버거가 중지 될 때까지 기다립니다.
Docker Compose 구성은 '디버그'모드에서 Jenkins 컨트롤러를 자동으로 시작합니다. 즉, 원격 디버그 요청을 듣고 있습니다. 코드가 컨트롤러에서 실행되면 localhost:8000 (Docker 컨테이너의 동일한 포트에 매핑)에 원격 디버거를 연결해야합니다. 제공된 Jenkins Controller (Remote Debugger) 디버그 구성을 사용하여 Intellij에서 디버거를 연결하십시오.
Docker Compose 구성은 또한 '디버그'모드에서 Jenkins 에이전트를 자동으로 시작합니다. 즉, 원격 디버그 요청을 듣고 있습니다. 에이전트에서 실행중인 디버그 코드에 localhost:8001 (Docker 컨테이너의 동일한 포트에 매핑)에 원격 디버거를 연결하십시오. 제공된 Jenkins Agent (Remote Debugger) 디버그 구성을 사용하여 Intellij에서 디버거를 연결하십시오.
UI 테스트는 해당 런처 UI Tests [module] (Firefox) 또는 UI Tests [module] (Chrome) 사용하여 시작할 수 있습니다. 두 발사기 모두 해당 셀레늄 드라이버를 설치해야합니다. 이 드라이버가 로컬 컴퓨터의 /opt/bin 에 설치되지 않은 경우 설정에 맞게 런처 구성을 조정해야합니다.
모든 UI 테스트는 테스트 중 주어진 주제 내에서 실행해야합니다 (예 : 테스트중인 Jenkins, JUT). 자세한 내용은 승인 테스트 하네스 프로젝트를 참조하십시오.
이 개발 환경에는 수정 된 플러그인을 배포 할 수있는 맞춤형 Jenkins 설치가 포함되어 있으므로이 플러그인을 사용하는 일부 미리 구성된 작업에서 직접 변경 사항을 확인할 수 있습니다.
이 프로젝트에서 제공된 Jenkins 컨트롤러를 시작하십시오 (Docker 및 Docker-Compose를 설치해야 함). 터미널을 열고 최상층 폴더에서 ./jenkins.sh 실행하십시오. 이 명령은 docker-compose up 의 래퍼입니다. 올바른 사용자 및 그룹 설정을 사용하여 Jenkins 홈 폴더의 Docker 볼륨의 권한이 올바르게 설정되도록합니다. 이 명령은 Jenkins 컨트롤러 용 Docker 컨테이너와 Java 에이전트 용 컨테이너를 만듭니다. Docker 이미지가 구성되기 때문에 처음으로 호출 된 시간이 필요합니다. 이미지가 만들어진 후 다음 두 컨테이너가 시작됩니다.
그런 다음 url http : // localhost : 8080/에서 Jenkins를 열 수 있습니다. 다음 자격 증명을 사용하여 관리자로 로그인하십시오.
Jenkins 컨트롤러 (Jenkins_home)의 홈 디렉토리는 Docker 볼륨으로 장착됩니다. 즉, 호스트에서 ./docker/volumes/jenkins-controller 의 일반 디렉토리로 보입니다. 세션에서 생존하고 호스트에서 직접 변경할 수 있습니다. 자세한 내용은 공식 문서를 참조하십시오. 이를 통해 Jenkins 컨트롤러가 작성한 파일을 검사하는 데 도움이됩니다.
Jenkins의 작업 DSL 플러그인의 성능 문제로 인해 새로운 Jenkins 인스턴스를 설정하는 것은 매우 느립니다. 따라서 작업이 작성된 후 jenkins.yaml 파일의 작업 구성 부분을 제거하는 것이 합리적입니다. jenkins-no-jobs.yaml ./docker/volumes/jenkins-home/jenkins.yaml 내용으로 새로 만든 Jenkins 인스턴스에서 파일의 내용을 덮어 쓸 수 있습니다.
MACOS의 볼륨은 매우 느립니다. 내 MacBook에서 Docker 컨테이너의 analysis-model 의 Jenkins 작업은 동일한 MacBook의 Linux 가상 시스템에서 실행중인 Docker 컨테이너에서 동일한 Jenkins 작업을 실행하는 것보다 느리게 진행됩니다 (Sound of Tackerd?).
지역 개발 변경을 완료 한 후에 (즉, 단위 테스트는 모두 녹색) Jenkins의 변경 사항을 테스트해야합니다. 또한 변경 사항에 대한 통합 테스트 또는 UI 테스트를 준비하는 데 도움이됩니다.
analysis-model 모듈에만 변경 사항이있는 경우 (새 API 메소드를 추가하지 않음) Maven 모듈 analysis-model.jar 재구성하고 설치해야합니다. 이후 관련 Jenkins 래퍼 플러그인 analysis-model-api-plugin 재 구축해야합니다. 이 플러그인은 Jenkins에 배포해야합니다.
이 프로세스는 analysis-model 모듈에서 스크립트 ./bin/go.sh 실행하여 단순화되며 로컬 Maven 리포지토리에 모듈 analysis-model.jar 설치합니다. 이 스크립트는 실제 플러그인을 빌드하여 Jenkins에 배포합니다.
경고 -NG 플러그인 만 변경되면 Jenkins 플러그인 warnings-ng.jpi 를 재건하고 Jenkins에 배포해야합니다. 이 작업에 다음 쉘 스크립트 중 하나를 사용할 수 있습니다.
./bin/clean.sh : mvn clean install 사용하여 플러그인을 빌드하고 Jenkins 인스턴스에 성공할 때 배포합니다../bin/go.sh : mvn clean install -DskipITs (통합 테스트를 건너 뜁니다)를 사용하여 플러그인을 빌드하고 Jenkins Instace에 성공할 때 배치합니다../bin/skip.sh : mvn clean install -DskipTests (모든 테스트 및 정적 분석을 건너 뜁니다)를 사용하여 플러그인을 빌드하고 Jenkins 인스턴스에 성공할 때 배포합니다.TODO
Foresics 플러그인 중 하나 (API 또는 GIT 구현)가 변경된 경우이 Jenkins 플러그인을 재건하고 Jenkins 인스턴스에 배포해야합니다.
이 프로세스를 단순화하기 위해 해당 플러그인 폴더에서 스크립트 ./go.sh 실행하면 플러그인을 빌드하여 Jenkins에 성공할 때 배포합니다.
깨지기 전에 나와 연락하십시오. 일반적으로 뒤로 변경할 수 있습니다.
마지막 섹션의 빌드 스크립트는 Build and Deploy [module-name] 사용하여 시작할 수도 있습니다. 이 런처는 해당 플러그인을 빌드하여 Jenkins에 배포합니다.
UI 테스트는 Intellij 런처 구성 또는 명령 줄 스크립트를 사용하여 시작할 수 있습니다. 이미 언급했듯이 모든 UI 테스트는 테스트중인 주어진 대상 내에서 실행해야합니다. 우리의 경우 우리는 Docker 이미지에서 최신 Jenkins LTS 버전과 사전 정의 된 플러그인 세트를 사용합니다.
UI 테스트는 해당 런처 UI Tests Warnings (Firefox) 또는 UI Warnings Tests (Chrome) 사용하여 시작할 수 있습니다. 두 발사기 모두 해당 셀레늄 드라이버를 설치해야합니다. 이 드라이버가 로컬 컴퓨터의 /opt/bin 에 설치되지 않은 경우 설정에 맞게 런처 구성을 조정해야합니다.
제공된 쉘 스크립트 testFirefox.sh 또는 testChrome.sh 를 사용하여 UI 테스트를 시작할 수도 있습니다. 이 스크립트도 조정해야 할 수도 있습니다 (이전 섹션 참조).