โครงการ Sonarsource นี้เป็นตัววิเคราะห์รหัสสำหรับโครงการ Java เพื่อช่วยให้นักพัฒนาผลิตรหัสที่สะอาด ข้อมูลเกี่ยวกับการวิเคราะห์คุณสมบัติ Java มีอยู่ที่นี่
เพื่อให้ข้อเสนอแนะ (ขอคุณสมบัติรายงานข้อผิดพลาด ฯลฯ ) ใช้ฟอรัมชุมชน Sonar โปรดอย่าลืมระบุภาษา (java!) เวอร์ชันปลั๊กอินและเวอร์ชัน Sonarqube
หากคุณมีคำถามเกี่ยวกับวิธีการใช้ปลั๊กอิน (และเอกสารไม่ได้ช่วยคุณ) เราขอแนะนำให้คุณใช้ฟอรัมชุมชน
หากต้องการขอคุณสมบัติใหม่โปรดสร้างเธรดใหม่ใน Forum Community Sonarqube แม้ว่าคุณจะวางแผนที่จะนำไปใช้ด้วยตัวเองและส่งกลับไปยังชุมชนโปรดเริ่มเธรดใหม่ก่อนเพื่อให้แน่ใจว่าเราสามารถใช้งานได้
หากต้องการส่งเงินบริจาคให้สร้างคำขอดึงสำหรับที่เก็บนี้ โปรดตรวจสอบให้แน่ใจว่าคุณทำตามสไตล์รหัสของเราและการทดสอบทั้งหมดกำลังผ่านไป (เช็คทั้งหมดต้องเป็นสีเขียว)
หากคุณมีความคิดสำหรับกฎ แต่คุณไม่แน่ใจว่าทุกคนต้องการมันคุณสามารถใช้กฎที่กำหนดเองได้สำหรับคุณเท่านั้น โปรดทราบว่าเพื่อช่วยคุณเราขอแนะนำให้ทำตามกฎการสอนที่กำหนดเอง 101 ก่อนที่จะดำน้ำโดยตรงในการใช้กฎตั้งแต่เริ่มต้น
คุณต้องการทำงานในโครงการนี้เต็มเวลาหรือไม่? เรากำลังจ้าง! ตรวจสอบ https://www.sonarsource.com/hiring
เพื่อเรียกใช้การทดสอบตามคำแนะนำเหล่านี้
คุณต้องใช้ Java 22 เพื่อสร้างโครงการและ Java 17 เรียกใช้การทดสอบการรวม (ITS)
Java 17 สามารถใช้ในการสร้างและทดสอบโมดูลทั้งหมดยกเว้นภายใต้แหล่งที่มา java-checks-test-sources ที่ต้องใช้ Java 22Java 22 สามารถใช้ในการสร้างและทดสอบโมดูลทั้งหมดยกเว้นภาย its ที่ต้องใช้ Java 17 เนื่องจากความไม่ลงรอยกันของ SQในการสร้างปลั๊กอินและเรียกใช้การทดสอบหน่วยให้ดำเนินการคำสั่งนี้จากไดเรกทอรีรูทของโครงการ:
mvn clean install
การทดสอบหน่วยที่ใช้งานภายใน IDE อาจเกิดขึ้นในบางประเด็นเนื่องจากวิธีการสร้างโครงการด้วย Maven ถ้าคุณเห็นอะไรแบบนี้:
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
ลองลบธรรมชาติ Maven ของโมดูล 'JDT'
ในการเรียกใช้การทดสอบการรวมคุณจะต้องสร้างไฟล์คุณสมบัติเช่นเดียวกับที่แสดงด้านล่างและตั้งค่า URL ที่ชี้ไปที่ตำแหน่งในตัวแปรสภาพแวดล้อมที่มีชื่อว่า ORCHESTRATOR_CONFIG_URL
# version of SonarQube Server
sonar.runtimeVersion=LATEST_RELEASE
orchestrator.updateCenterUrl=http://update.sonarsource.org/update-center-dev.properties
# The location of the Maven local repository is not automatically guessed. It can also be set with the env variable MAVEN_LOCAL_REPOSITORY.
maven.localRepository=/home/myName/.m2/repository
ด้วยตัวอย่างเช่นตัวแปร ORCHESTRATOR_CONFIG_URL ถูกตั้งค่าเป็น:
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
ก่อนที่จะเรียกใช้ ITS ให้แน่ใจว่าตั้งค่าตัวแปรสภาพแวดล้อม Maven_home ของคุณ
"การทดสอบความสุข" เป็นการทดสอบที่เรียกใช้การตรวจสอบทั้งหมดกับไฟล์ต้นทางทดสอบทั้งหมดโดยไม่คำนึงถึงผลลัพธ์ของการวิเคราะห์ มันตรวจสอบว่ากฎไม่ล่มในไฟล์ใด ๆ ในแหล่งทดสอบของเรา โดยค่าเริ่มต้นการทดสอบนี้ไม่รวมอยู่ในบิลด์ เพื่อเปิดตัว:
mvn clean install -P sanity
"การทดสอบปลั๊กอิน" เป็นชุดทดสอบการรวมที่ตรวจสอบคุณสมบัติปลั๊กอินเช่นการคำนวณตัวชี้วัดความครอบคลุม ฯลฯ เพื่อเปิดตัว:
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
หมายเหตุสำหรับผู้มีส่วนร่วมภายใน: เพื่อดำเนินการทดสอบที่ขึ้นอยู่กับ Sonarqube Enterprise Edition ใช้:
mvn clean install -Pit-plugin
"การทดสอบการปกครอง" เป็นชุดทดสอบการรวมที่เปิดการวิเคราะห์ฐานรหัสขนาดใหญ่บันทึกปัญหาที่สร้างขึ้นโดยปลั๊กอินในไฟล์รายงานจากนั้นเปรียบเทียบผลลัพธ์เหล่านั้นกับชุดของปัญหาที่คาดหวัง (เก็บเป็นไฟล์ JSON)
ในการเรียกใช้การทดสอบก่อนอื่นตรวจสอบให้แน่ใจว่ามีการตรวจสอบ submodules:
git submodule update --init --recursive
จากนั้นตรวจสอบให้แน่ใจว่าตัวแปรสภาพแวดล้อม JAVA_HOME ถูกตั้งค่าสำหรับการดำเนินการทดสอบการพิจารณาคดีและชี้ไปที่การติดตั้ง JDK 17 ในพื้นที่ของคุณ ความล้มเหลวในการทำเช่นนั้นจะสร้างความไม่สอดคล้องกับผลลัพธ์ที่คาดหวัง
จากโฟลเดอร์ its/ruling เปิดตัวการทดสอบการพิจารณาคดี:
mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java17/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
หมายเหตุสำหรับผู้มีส่วนร่วมภายใน: เพื่อดำเนินการทดสอบที่ขึ้นอยู่กับ Sonarqube Enterprise Edition ใช้:
mvn clean install -Pit-ruling
การทดสอบนี้เปิดโอกาสให้คุณตรวจสอบปัญหาที่สร้างขึ้นโดยแต่ละกฎและตรวจสอบให้แน่ใจว่าพวกเขาเป็นสิ่งที่คุณคาดหวัง กฎที่ดำเนินการใด ๆ มีแนวโน้มสูงที่จะยกประเด็นในหลายโครงการที่เราใช้เป็นฐานรหัสการปกครอง
สำหรับกฎที่นำมาใช้ใหม่หมายความว่าการสร้างครั้งแรกอาจล้มเหลวส่วนใหญ่เกิดจากความแตกต่างระหว่างผลลัพธ์ที่คาดหวัง (โดยไม่มีค่าใด ๆ สำหรับกฎใหม่) และผลลัพธ์ใหม่ คุณสามารถตรวจสอบปัญหาใหม่เหล่านี้ได้โดยการค้นหาไฟล์ที่ตั้งชื่อตามกฎของคุณ ( squid-SXXXX.json ) ในโฟลเดอร์ต่อไปนี้:
/path/to/project/sonar-java/its/ruling/target/actual/...
สำหรับกฎที่มีอยู่ซึ่งได้รับการแก้ไขคุณอาจคาดหวังความแตกต่างระหว่าง "จริง" (จากการวิเคราะห์ใหม่) และผลลัพธ์ที่คาดหวัง ตรวจสอบการเปลี่ยนแปลงที่แสดงและอัปเดตทรัพยากรที่คาดหวังอย่างรอบคอบ
ไฟล์ json ทั้งหมดมีรายการบรรทัดที่จัดทำดัชนีโดยไฟล์อธิบายว่าปัญหาที่เกิดขึ้นจากกฎเฉพาะจะอยู่ที่ไหน ถ้า/เมื่อทุกอย่างดูดีสำหรับคุณคุณสามารถคัดลอกไฟล์ด้วยปัญหาจริงที่อยู่ที่:
its/ruling/target/actual/
ลงในไดเรกทอรีที่มีปัญหาที่คาดหวัง:
its/ruling/src/test/resources/
ตัวอย่างเช่นการใช้คำสั่ง:
cp its/ruling/target/actual/* its/ruling/src/test/resources/
การทดสอบในโมดูล Autoscan ได้รับการออกแบบมาเพื่อตรวจจับความแตกต่างระหว่างปัญหาที่ Java Analyzer สามารถค้นหาได้มีและไม่มี bytecode เป้าหมายที่นี่คือการมองเห็นและแก้ไข FP ที่มีศักยภาพและตรวจสอบ FNs ที่คาดหวังระหว่างที่จะปรากฏในการวิเคราะห์อัตโนมัติของ Sonarcloud
การรันการทดสอบนี้สามารถแบ่งออกเป็น 2 ขั้นตอน:
java-checks-tests-sources (เช่นไฟล์. class ใน java-checks-tests-sources/target/ เป็นปัจจุบัน)
สงสัยว่าไปที่โมดูล java-checks-tests-sources และ Run:
# Use java 22!
mvn clean compile ในการเรียกใช้การทดสอบให้ย้ายไปที่โฟลเดอร์ its/autoscan และเรียกใช้:
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version
--activate-profiles it-autoscan
-Dsonar.runtimeVersion=LATEST_RELEASE สิ่งประดิษฐ์ที่ผลิตในระหว่างการดำเนินการทดสอบจะพบได้ใน its/autoscan/target/actual คุณจะต้องเปรียบเทียบผลลัพธ์ที่เกิดขึ้นใน Autoscan-Diff-by-Rules
สำหรับข้อมูลรายละเอียดเพิ่มเติมคุณสามารถเปรียบเทียบความแตกต่างระหว่างผลลัพธ์ที่พบกับ bytecode และไม่มี bytecode โดยการเปรียบเทียบสองโฟลเดอร์ที่เกี่ยวข้อง:
ขึ้นอยู่กับผลลัพธ์ที่พบคุณอาจต้องอัปเดตความจริงพื้นฐาน ผลลัพธ์ที่คาดหวังแสดงอยู่ใน SRC/ทดสอบ/ทรัพยากร
คุณสามารถดีบักได้โดยการเพิ่ม -Dmaven.binary=mvnDebug เป็นตัวเลือกเมื่อเรียกใช้การทดสอบ สิ่งนี้จะทำให้เครื่องวิเคราะห์ JVM รอการดีบักเกอร์ที่จะแนบก่อนดำเนินการต่อ
ลิขสิทธิ์ 2012-2024 Sonarsource
นักวิเคราะห์ Sonarqube เปิดตัวหลังจากวันที่ 29 พฤศจิกายน 2567 รวมถึงการแก้ไขแพตช์สำหรับเวอร์ชันก่อนหน้านี้ได้รับการเผยแพร่ภายใต้ใบอนุญาต SONAR-Available License เวอร์ชัน 1 (SSALV1)
ดูแต่ละไฟล์สำหรับรายละเอียดที่ระบุสิทธิ์การใช้งานที่ใช้กับแต่ละไฟล์ ไฟล์ที่อยู่ภายใต้ SSALV1 จะถูกบันทึกไว้ในส่วนหัวของพวกเขา