ฉันมีประสบการณ์ค่อนข้างยาวกับกระบวนการทํางานของ GitHub แต่ไม่ถึงจุดที่ฉันสามารถเรียกร้องว่าฉันเป็นผู้เชี่ยวชาญ อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันได้พัฒนากระบวนการทํางานใหม่และมันกระตุ้นให้ฉันเขียนโพสต์นี้ คุณสามารถเพิ่มของคุณเองได้ กระบวนการทํางาน GitHub คืออะไร กระบวนการทํางานเป็นกระบวนการอัตโนมัติที่สามารถกําหนดค่าได้ซึ่งจะเรียกใช้งานหนึ่งหรือมากกว่า กระบวนการทํางานจะถูกกําหนดโดยไฟล์ YAML ที่เข้าสู่การจัดเก็บข้อมูลของคุณและจะเรียกใช้เมื่อมีการเปิดใช้งานโดยเหตุการณ์ในจัดเก็บข้อมูลของคุณหรือสามารถเปิดใช้งานได้ด้วยตนเองหรือตามเวลาที่กําหนด กระบวนการทํางานถูกกําหนดไว้ในไดเรกทอรี .github/workflows ในภาชนะเก็บข้อมูล โพสต์สามารถมีกระบวนการทํางานหลายกระบวนการซึ่งแต่ละกระบวนการสามารถดําเนินการกับชุดงานที่แตกต่างกันเช่น: การสร้างและการทดสอบการพึงคําขอ การใช้แอปพลิเคชันของคุณทุกครั้งที่สร้างการเปิดตัว เพิ่มฉลากทุกครั้งที่เปิดปัญหาใหม่ -- เกี่ยวกับ Workflows กระบวนการทํางานเป็นกระบวนการอัตโนมัติที่สามารถกําหนดค่าได้ซึ่งจะเรียกใช้งานหนึ่งหรือมากกว่า กระบวนการทํางานจะถูกกําหนดโดยไฟล์ YAML ที่เข้าสู่การจัดเก็บข้อมูลของคุณและจะเรียกใช้เมื่อมีการเปิดใช้งานโดยเหตุการณ์ในจัดเก็บข้อมูลของคุณหรือสามารถเปิดใช้งานได้ด้วยตนเองหรือตามเวลาที่กําหนด กระบวนการทํางานถูกกําหนดไว้ในไดเรกทอรี .github/workflows ในภาชนะเก็บข้อมูล โพสต์สามารถมีกระบวนการทํางานหลายกระบวนการซึ่งแต่ละกระบวนการสามารถดําเนินการกับชุดงานที่แตกต่างกันเช่น: การสร้างและการทดสอบการพึงคําขอ การใช้แอปพลิเคชันของคุณทุกครั้งที่สร้างการเปิดตัว เพิ่มฉลากทุกครั้งที่เปิดปัญหาใหม่ -- เกี่ยวกับ Workflows ดังนั้นกระบวนการทํางานสามารถเปรียบเทียบได้กับงาน Jenkins ซึ่งดําเนินการใน YAML แทน XML อย่างไรก็ตามความแตกต่างหลักคือการกําหนดค่ากระบวนการทํางานคือ ในทางตรงกันข้ามกับการกําหนดค่างานของ Jenkins ที่อยู่เบื้องหลัง มันดูเหมือนไม่มาก แต่ช่วยให้สามารถใช้วิธีการจัดการรหัสแหล่งที่มารวมถึงการสร้างเวอร์ชันและการลากกลับได้หลายปีที่ผ่านมาฉันทํางานสําหรับลูกค้าที่ทีมของ DevOps ได้ใช้วิธีการขึ้นอยู่กับ Puppet เพื่อสร้างงานของ Jenkins เพื่อให้การกําหนดค่า Puppet สามารถเก็บไว้ใน Git มันเป็นความพยายามอย่างมาก! stored inside the code repository โปรดทราบว่า GitHub นั้นค่อนข้างล่าช้าสําหรับปาร์ตี้ ก่อนที่จะใช้กระบวนการทํางานฉันใช้บริการของบุคคลที่สามที่เรียกว่า ฉันเปลี่ยนส่วนใหญ่เนื่องจาก Travis ได้รับการชําระเงินและส่วนใหญ่เนื่องจากกระบวนการทํางานเป็นส่วนหนึ่งของ GitHub เฟอร์นิเจอร์ Tip: : พวกเขาเรียกว่า . การกระทํา GitHub มีความแตกต่างอย่างสมบูรณ์ Use the correct semantics กระบวนการทํางานของ GitHub GitHub การกระทํา กระบวนการทํางานของ GitHub ประกอบด้วย ซึ่งด้วยตัวเองประกอบด้วย ขั้นตอนการอ้างอิง คําสั่งและพารามิเตอร์สองตัวเลือกรวมถึงชื่อ งาน ขั้นตอน แข่ง jobs: metrics: runs-on: my-image #1 steps: - name: Install dependencies via Poetry #2 run: poetry install #3 รูปภาพ OCI ที่ทํางานกระแส ชื่อขั้นตอน ขั้นตอนคําสั่ง การกระทํา GitHub เป็นส่วนประกอบที่สามารถใช้ซ้ําได้ซึ่งมีทางเลือกในการทําซ้ําคําสั่งเดียวกันอีกครั้งและอีกครั้ง การกระทําคือชุดงานหรือโค้ดที่กําหนดไว้ล่วงหน้าและสามารถใช้ซ้ําได้ซึ่งจะดําเนินการงานเฉพาะภายในกระบวนการทํางานซึ่งจะช่วยลดปริมาณโค้ดซ้ําที่คุณเขียนในไฟล์กระบวนการทํางานของคุณ การกระทําสามารถดําเนินการเช่น: การดึงเก็บข้อมูล Git ของคุณจาก GitHub การตั้งค่าโซ่เครื่องมือที่เหมาะสมสําหรับสภาพแวดล้อมการสร้างของคุณ การตั้งค่าการรับรองสําหรับผู้ให้บริการคลาวด์ของคุณ คุณสามารถเขียนการกระทําของคุณเองหรือคุณสามารถค้นหาการกระทําที่จะใช้ในกระบวนการทํางานของคุณใน GitHub Marketplace ตัวอย่างเช่นแทนที่จะดําเนินการ git checkout คุณสามารถใช้การกระทํา checkout GitHub การกระทํา แอน เป็นชุดงานหรือโค้ดที่กําหนดไว้ล่วงหน้าและสามารถนํามาใช้ซ้ําได้ซึ่งดําเนินการงานเฉพาะภายในระบบ ลดปริมาณโค้ดซ้ําที่คุณเขียนลงในไฟล์กระบวนการทํางานของคุณ การกระทําสามารถดําเนินการเช่น: action workflow การดึงเก็บข้อมูล Git ของคุณจาก GitHub การตั้งค่าโซ่เครื่องมือที่เหมาะสมสําหรับสภาพแวดล้อมการสร้างของคุณ การตั้งค่าการรับรองสําหรับผู้ให้บริการคลาวด์ของคุณ คุณสามารถเขียนการกระทําของคุณเองหรือคุณสามารถค้นหาการกระทําที่จะใช้ในกระบวนการทํางานของคุณใน ตัวอย่างเช่นแทนที่จะดําเนินการ คุณสามารถใช้ . GitHub ตลาด git checkout การกระทํา Checkout GitHub การกระทํา jobs: metrics: runs-on: my-image steps: - uses: actions/checkout@v5 #1 with: #2 fetch-depth: 0 submodules: recursive การอ้างอิงการกระทํา GitHub พารามิเตอร์การกระทํา ฉันเป็นแฟนใหญ่ของไม่คิดค้นล้อใหม่ GitHub การกระทํามีบทบาทสําคัญในเรื่องนี้ Tip: เมื่อเป็นไปได้ Prefer GitHub Actions over ad-hoc commands เลือกการกระทําที่เหมาะสม โฮสติ้ง GitHub Marketplace การกระทําจะระบุตามหมวดหมู่ คุณสามารถกรองตามประเภทผู้สร้างและจัดเรียงตามความนิยม การกระทํามากมาย เมื่อเลือกการกระทําคุณควรใช้ความระมัดระวังเช่นเดียวกับเมื่อนําไปสู่การติดยาเสพติดอื่น ๆ นี่คือสองเกณฑ์ที่จะช่วยคุณ: Vendor: prefer verified creators License type: Open Source vs. closed source. With the former, check the exact terms; the Apache v2 license is very different from the GPL one. Pricing for commercial actions Check the source code repository of actions that display it and check the following information: ** Inception date ** Activity, including the repartition of commits per committer, the number of open issues, the mean time for fixing issues, etc. ** Documentation (reference material, tutorials, how-to guides, and explanations) Community, if any Support Tip: Be as careful in choosing a GitHub Action as in choosing any other dependency. รู้การกระทําของคุณ เช่นเดียวกับเคล็ดลับก่อนหน้านี้นี้มาจากหนึ่งทั่วไปมากขึ้น - ฉันพูดจากประสบการณ์ ฉันกําลังพัฒนากระบวนการทํางานเพื่อแพคเกจแอพพลิเคชัน Java ฉันใช้กระบวนการทํางานอย่างหนักและงานต้องดาวน์โหลดการพึ่งพาทุกครั้ง jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 - uses: actions/setup-java@v4 #1 with: distribution: temurin java-version: 21 - uses: actions/cache@v4 #2 with: path: ~/.m2/repository #3 key: ${{ platform }}-maven--${{ hashFiles('**/pom.xml') }} #4 restore-keys: | ${{ runner.os }}-maven- #4 ติดตั้ง JDK การตั้งค่าแคช แคชเป็นแบบทั่วไปและสามารถแคชไฟล์ผ่านการทํางาน Cache โพสต์ท้องถิ่น Maven คีย์ใช้ OS Runner ซึ่งไม่เปลี่ยนแปลงและ hash ของ POM ดังนั้นขั้นตอนนี้จะสร้าง cache ใหม่ทุกครั้งที่ POM เปลี่ยน อย่างไรก็ตามการอ่านเอกสารฉันรู้ว่าฉันสามารถบรรลุได้ด้วยวิธีที่เรียบง่ายมากขึ้น: การกระทํานี้มีฟังก์ชั่นในตัวสําหรับการแคชและการกู้คืนอิสระ มันใช้ชุดเครื่องมือ / แคชภายใต้ฝาครอบสําหรับการแคชอิสระ แต่ต้องมีการตั้งค่าการกําหนดค่าน้อยลง ผู้จัดการแพคเกจที่ได้รับการสนับสนุนคือ gradle, maven และ sbt รูปแบบของคีย์แคชที่ใช้คือ setup-java-${{แพลตฟอร์ม }}-${ packageManager }}-${ fileHash }} ซึ่งแฮชจะขึ้นอยู่กับไฟล์ต่อไปนี้: Maven: **/pom.xml -- แพคเกจ Caching Dependencies การกระทํานี้มีฟังก์ชั่นในตัวสําหรับการแคชและการกู้คืนอิสระ มันใช้ชุดเครื่องมือ / cache ภายใต้ฝาครอบสําหรับการแคชอิสระ แต่ต้องมีการตั้งค่าการกําหนดค่าน้อยลง ผู้จัดการแพคเกจที่สนับสนุนคือ gradle, maven และ sbt รูปแบบของคีย์แคชที่ใช้คือ ที่แฮชจะขึ้นอยู่กับไฟล์ต่อไปนี้: setup-java-${{ platform }}-${{ packageManager }}-${{ fileHash }} Maven: **/pom.xml -- แพคเกจ Caching Dependencies ดังนั้นฉันแทนที่ snippet ด้านบนด้วยดังต่อไปนี้: jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 - uses: actions/setup-java@v4 with: distribution: temurin java-version: 21 cache: maven #1 นี่คือ Tip: การใช้เวลาหนึ่งชั่วโมงในการทําเอกสารสามารถช่วยให้คุณประหยัดเวลา Thoroughly read the documentation of actions. Pin เวอร์ชันการพึ่งพาของคุณ ส่วนนี้ยังใช้คําแนะนําทั่วไปและใช้กับเวอร์ชันของ GitHub Workflows คุณสามารถหาเวอร์ชันในสองสถานที่อย่างน้อย: รูปภาพ OCI และเวอร์ชันของ GitHub Actions คุณอาจสังเกตเห็น ใน snippets ก่อนหน้านี้ ในช่วงเวลาของการเขียนนี้มันแสดงให้เห็นว่า เมื่อเวลาผ่านไปมันจะชี้ให้เห็นถึงรุ่นล่าสุดพร้อมกับรุ่นของห้องสมุดที่แตกต่างกัน มันอาจทําให้เกิดความล้มเหลวในระหว่างการทํางานของกระบวนการทํางานหรือแย่กว่านั้นเปลี่ยนการส่งออกในลักษณะที่คุณจะไม่สังเกตเห็นจนกว่าจะล่าช้า คุณควรตั้งค่าเวอร์ชันเฉพาะ ตรวจสอบ [ภาพทั้งหมดที่มีอยู่] runs-on: ubuntu-latest ubuntu-24.04 https://github.com/actions/runner-images การปรับรุ่นของ Actions ทํางานได้แตกต่างกันเนื่องจากพวกเขามุ่งเน้นไปที่การอ้างอิงของ GitHub repo: แท็กหรือ Commit SHA ในขณะที่ภาพ OCI อยู่ในมือของ GitHub การกระทําเป็นความรับผิดชอบของผู้ให้บริการของมัน หมายความว่าใครก็ตามที่มีสิทธิรับสัญญาสามารถเปลี่ยนเนื้อหาของแท็กพื้นฐาน หากคุณใช้ความปลอดภัยอย่างจริงจังคุณจะ pin ไปยัง a commit must jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@08c6903 #1 Pin ไปยัง commit โดยเฉพาะอย่างยิ่ง 💡 เคล็ดลับ: ใช้ความปลอดภัยอย่างจริงจังและ pin actions to a specific commit. ใช้สรุปงาน แต่ละขั้นตอนของกระบวนการทํางานของคุณอาจส่งออกบันทึกจํานวนมาก ในกระบวนการทํางานปกติจํานวนเส้นบันทึกโดยรวมอาจค่อนข้างใหญ่ บางส่วนอาจเป็นประโยชน์บางส่วนอาจไม่ได้ แต่เนื่องจากมีเพียงเอาท์พุทมาตรฐานและข้อผิดพลาดมาตรฐานทุกอย่างจบลงในสถานที่เดียวกัน อย่างไรก็ตามคุณอาจต้องการที่จะมุ่งเน้นข้อมูลเฉพาะ , จํานวนการทดสอบที่ดําเนินการหรือเปอร์เซ็นต์ของการครอบคลุมรหัสในกรณีที่คุณไม่ได้ส่งข้อมูลเหล่านี้ไปยังที่อื่น ๆ GitHub ทําให้การเพิ่มข้อมูลที่คุณต้องการลงในสรุปงานง่ายขึ้น แพทย์ คุณสามารถตั้งค่าการทําเครื่องหมายที่กําหนดเองสําหรับแต่ละงานเพื่อให้ปรากฏบนหน้าสรุปของกระบวนการทํางาน คุณสามารถใช้สรุปงานเพื่อแสดงและกลุ่มเนื้อหาที่ไม่ซ้ํากันเช่นสรุปผลการทดสอบเพื่อให้บุคคลที่ดูผลการทํางานของกระบวนการทํางานไม่จําเป็นต้องเข้าสู่บันทึกเพื่อดูข้อมูลสําคัญที่เกี่ยวข้องกับกระบวนการทํางานเช่นความล้มเหลว คําอธิบายงานรองรับ GitHub aromated Markdown และคุณสามารถเพิ่มเนื้อหา Markdown ของคุณสําหรับขั้นตอนหนึ่งไปยังไฟล์สภาพแวดล้อม GITHUB_STEP_SUMMARY GITHUB_STEP_SUMMARY เป็นเอกลักษณ์สําหรับแต่ละขั้นตอนในงาน -- เพิ่มสรุปงาน คุณสามารถตั้งค่าการทําเครื่องหมายที่กําหนดเองสําหรับแต่ละงานเพื่อให้ปรากฏบนหน้าสรุปของกระบวนการทํางาน คุณสามารถใช้สรุปงานเพื่อแสดงและกลุ่มเนื้อหาที่ไม่ซ้ํากันเช่นสรุปผลการทดสอบเพื่อให้บุคคลที่ดูผลการทํางานของกระบวนการทํางานไม่จําเป็นต้องเข้าสู่บันทึกเพื่อดูข้อมูลสําคัญที่เกี่ยวข้องกับกระบวนการทํางานเช่นความล้มเหลว คําอธิบายงานรองรับ GitHub aromated Markdown และคุณสามารถเพิ่มเนื้อหา Markdown ของคุณสําหรับขั้นตอน ไฟล์สภาพแวดล้อม เป็นเอกลักษณ์สําหรับแต่ละขั้นตอนในงาน GITHUB_STEP_SUMMARY GITHUB_STEP_SUMMARY -- เพิ่มสรุปงาน นี่ a จาก Apache Arrow: ตัวอย่าง - name: Show inputs run: | echo "upload_artifacts: ${{ inputs.upload_artifacts }}" >> $GITHUB_STEP_SUMMARY echo "schedule: ${{ github.event.schedule }}" >> $GITHUB_STEP_SUMMARY echo "ref: ${{ github.ref }}" >> $GITHUB_STEP_SUMMARY โซ เป็น: ผล Tip: เพื่อเพิ่มประสบการณ์ของนักพัฒนา Use GitHub job summary ทําความเข้าใจเกี่ยวกับวงจรชีวิตของกระบวนการทํางาน กระบวนการทํางานเรียกใช้ขั้นตอนตามลําดับ ขั้นตอนที่ผิดพลาดจะยกเลิกขั้นตอนที่เหลือทั้งหมดและกระบวนการทํางานจะจบลงในขั้นตอนที่ผิดพลาด ในตัวอย่างข้างต้นหมายความว่าเราจะไม่ได้รับการสรุปการทดสอบใด ๆ หากขั้นตอนต่อไปนี้ล้มเหลว มันเป็นไปได้ที่จะหลีกเลี่ยงพฤติกรรมเริ่มต้นนี้โดยใช้แนวทางที่ตรงกันข้าม เงื่อนไข Failure if คุณสามารถใช้ฟังก์ชั่นการตรวจสอบสถานะต่อไปนี้เป็นตัวอักษรใน if conditionals การตรวจสอบสถานะเริ่มต้นของ success() จะถูกนํามาใช้เว้นแต่คุณจะรวมฟังก์ชั่นเหล่านี้ --ฟังก์ชั่นการตรวจสอบสถานะ คุณสามารถใช้ฟังก์ชั่นการตรวจสอบสถานะต่อไปนี้เป็นตัวอักษรใน if conditionals การตรวจสอบสถานะเริ่มต้นของ success() จะถูกนํามาใช้เว้นแต่คุณจะรวมฟังก์ชั่นเหล่านี้ --ฟังก์ชั่นการตรวจสอบสถานะ GitHub ใช้ โดยค่าเริ่มต้น แต่ตัวเลือกรวมถึง , และ . success() always() cancelled() failure() - name: Show inputs if: ${{ always() }} #1 run: | echo "upload_artifacts: ${{ inputs.upload_artifacts }}" >> $GITHUB_STEP_SUMMARY echo "schedule: ${{ github.event.schedule }}" >> $GITHUB_STEP_SUMMARY echo "ref: ${{ github.ref }}" >> $GITHUB_STEP_SUMMARY ดําเนินขั้นตอนเสมอไม่ว่าขั้นตอนก่อนหน้านี้ประสบความสําเร็จหรือไม่ ตอนนี้จินตนาการลําดับต่อไปนี้: - name: Step that may fail run: whatever - name: Execute unit tests run: ./mvnw -B test #1 - name: Test Summary if: ${{ always() }} uses: test-summary/action@31493c7 #2 การทดสอบหน่วยทํางานยังสร้างรายงาน JUnit ใช้รายงาน JUnit ที่สร้างขึ้นเพื่อเขียนสรุปขั้นตอน หากขั้นตอนแรกล้มเหลวการสรุปจะดําเนินการโดยไม่คํานึงถึงว่าการทดสอบถูกเรียกใช้หรือไม่ หากพวกเขาไม่ได้มันจะล้มเหลว เพื่อหลีกเลี่ยงสิ่งนี้เราต้องปรับปรุงเงื่อนไขต่อไปเพื่อให้ขั้นตอนสรุปทํางานได้เฉพาะหากขั้นตอนการทดสอบหน่วยทํา - name: Step that may fail run: whatever - name: Execute unit tests id: test #1 run: ./mvnw -B test - name: Test Summary if: ${{ always() && steps.test.conclusion == 'success'}} #2 uses: test-summary/action@31493c7 กําหนด ID ของขั้นตอน ดําเนินการเฉพาะเมื่อขั้นตอนการทดสอบประสบความสําเร็จ มันเป็นเพียงตัวอย่างที่เรียบง่าย แต่มีตัวเลือกที่น่าสนใจ Tip: และใช้มันเพื่อประโยชน์ของคุณ Know workflows' lifecycle การทดสอบในท้องถิ่น หลายองค์กรบังคับใช้กฎ GitHub อย่างเคร่งครัด หนึ่งที่แพร่กระจายมากที่สุดคือคุณไม่สามารถกดเพื่อ : แต่ละคอมมิชชั่นต้องผ่านการร้องขอการดึง แม้ว่ามันมีความหมายสําหรับโครงการที่จัดตั้งขึ้น แต่ก็ป้องกันไม่ให้โครงการเริ่มต้นซ้ําได้อย่างรวดเร็วในขณะที่ยังคงประวัติการคอมมิชชั่น ในแง่มุมของการพัฒนากระบวนการทํางานของ GitHub มันเป็นอย่างแน่นอน crippling master มาถึงโครงการกระทํา: “คิดทั่วโลกกระทําในท้องถิ่น” ดําเนินการการกระทํา GitHub ของคุณในท้องถิ่น! ทําไมคุณต้องการทําสิ่งนี้? มีสองเหตุผล: - Rather than having to commit/push every time you want to test out the changes you are making to your files (or for any changes to embedded GitHub actions), you can use act to run the actions locally. The environment variables and filesystem are all configured to match what GitHub provides. Fast Feedback .github/workflows/ - I love make. However, I also hate repeating myself. With , you can use the GitHub Actions defined in your to replace your ! Local Task Runner act .github/workflows/ Makefile - การแนะนําให้กระทํา “คิดทั่วโลกกระทําในท้องถิ่น” ดําเนินการการกระทํา GitHub ของคุณในท้องถิ่น! ทําไมคุณต้องการทําสิ่งนี้? มีสองเหตุผล: ความคิดเห็นที่รวดเร็ว - แทนที่จะต้องกระตุ้น / กระตุ้นทุกครั้งที่คุณต้องการทดสอบการเปลี่ยนแปลงที่คุณทําใน .github / ทํางาน / ไฟล์ (หรือสําหรับการเปลี่ยนแปลงใด ๆ ไปยังการกระทํา GitHub ในตัว) คุณสามารถใช้การกระทําเพื่อเรียกใช้การกระทําในท้องถิ่น ตัวแปรสภาพแวดล้อมและระบบไฟล์ทั้งหมดได้รับการกําหนดค่าเพื่อสอดคล้องกับสิ่งที่ GitHub ให้ Local Task Runner - ฉันรักการทํา อย่างไรก็ตามฉันไม่ชอบการทําซ้ําด้วยตัวเอง ด้วยการกระทําคุณสามารถใช้การกระทํา GitHub ที่กําหนดไว้ใน .github/workflows/ ของคุณเพื่อแทนที่ Makefile ของคุณ! - - การแนะนํา act มีการบูรณาการ CLI ของ GitHub ที่เปิดใช้งานกระบวนการทํางานตามเหตุการณ์ที่ถูกต้อง ลองจําลองการกด: act gh act push นี่คือผลลัพธ์เมื่อภาพและการกระทําได้รับการดาวน์โหลดแล้ว: INFO[0000] Using docker host 'unix:///var/run/docker.sock', and daemon socket 'unix:///var/run/docker.sock' [workflow.yml/test] ⭐ Run Set up job [workflow.yml/test] 🚀 Start image=catthehacker/ubuntu:act-22.04 [workflow.yml/test] 🐳 docker pull image=catthehacker/ubuntu:act-22.04 platform= username= forcePull=true [workflow.yml/test] 🐳 docker create image=catthehacker/ubuntu:act-22.04 platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="host" [workflow.yml/test] 🐳 docker run image=catthehacker/ubuntu:act-22.04 platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="host" [workflow.yml/test] 🐳 docker exec cmd=[node --no-warnings -e console.log(process.execPath)] user= workdir= [workflow.yml/test] ✅ Success - Set up job [workflow.yml/test] ☁ git clone 'https://github.com/actions/setup-java' # ref=v4 [workflow.yml/test] ⭐ Run Main actions/checkout@v4 [workflow.yml/test] 🐳 docker cp src=/Users/nico/projects/act-sample/. dst=/Users/nico/projects/act-sample [workflow.yml/test] ✅ Success - Main actions/checkout@v4 [9.211777902s] [workflow.yml/test] ⭐ Run Main Setup JDK [workflow.yml/test] 🐳 docker cp src=/home/nico/.cache/act/actions-setup-java@v4/ dst=/var/run/act/actions/actions-setup-java@v4/ [workflow.yml/test] 🐳 docker exec cmd=[/opt/acttoolcache/node/18.20.8/x64/bin/node /var/run/act/actions/actions-setup-java@v4/dist/setup/index.js] user= workdir= [workflow.yml/test] ❓ ::group::Installed distributions | Resolved Java 21.0.8+9.0.LTS from tool-cache | Setting Java 21.0.8+9.0.LTS as the default | Creating toolchains.xml for JDK version 21 from temurin | Writing to /root/.m2/toolchains.xml | | Java configuration: | Distribution: temurin | Version: 21.0.8+9.0.LTS | Path: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64 | [workflow.yml/test] ❓ ::endgroup:: [workflow.yml/test] ❓ add-matcher /run/act/actions/actions-setup-java@v4/.github/java.json | Creating settings.xml with server-id: github | Writing to /root/.m2/settings.xml [workflow.yml/test] ⚙ *** | Cache Size: ~50 MB (52710428 B) | [command]/usr/bin/tar -xf /tmp/c8ef4803-85c1-4867-ac2d-442dbce79755/cache.tzst -P -C /Users/nico/projects/act-sample --use-compress-program unzstd | Cache restored successfully | Cache restored from key: setup-java-linux-x64-maven-ef0e54e9035c18b60db7ea0af5e2f0c4cc5445dd6a2a2a672b91e14f14e7e4c2 [workflow.yml/test] ✅ Success - Main Setup JDK [2.514565962s] [workflow.yml/test] ⚙ ::set-env:: JAVA_HOME=/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64 [workflow.yml/test] ⚙ ::set-env:: JAVA_HOME_21_X64=/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64 [workflow.yml/test] ⚙ ::set-output:: distribution=Temurin-Hotspot [workflow.yml/test] ⚙ ::set-output:: path=/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64 [workflow.yml/test] ⚙ ::set-output:: version=21.0.8+9.0.LTS [workflow.yml/test] ⚙ ::set-output:: cache-hit=false [workflow.yml/test] ⚙ ::add-path:: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64/bin [workflow.yml/test] ⭐ Run Main Run "fast" tests [workflow.yml/test] 🐳 docker exec cmd=[bash -e /var/run/act/workflow/2] user= workdir= | [INFO] Scanning for projects... | [INFO] | [INFO] ----< ch.frankel.blog:act-sample >----- | [INFO] Building act-sample 1.0-SNAPSHOT | [INFO] from pom.xml | [INFO] ------------------------[ jar ]------------------------- | [INFO] | [INFO] --- resources:3.3.1:resources (default-resources) @ act-sample --- | [INFO] Copying 1 resource from src/main/resources to target/classes | [INFO] | [INFO] --- compiler:3.14.0:compile (default-compile) @ act-sample --- | [INFO] Recompiling the module because of changed source code. | [INFO] Compiling 5 source files with javac [debug target 21] to target/classes | [INFO] | [INFO] --- resources:3.3.1:testResources (default-testResources) @ act-sample --- | [INFO] Copying 2 resources from src/test/resources to target/test-classes | [INFO] | [INFO] --- compiler:3.14.0:testCompile (default-testCompile) @ act-sample --- | [INFO] Recompiling the module because of changed dependency. | [INFO] Compiling 1 source file with javac [debug target 21] to target/test-classes | [INFO] | [INFO] --- surefire:3.2.5:test (default-test) @ act-sample --- | [INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider | [INFO] | [INFO] ------------------------------------------ | [INFO] T E S T S | [INFO] ------------------------------------------ | [INFO] Running ch.frankel.blog.ActSampleTest | [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.120 s -- in ch.frankel.blog.ActSampleTest | [INFO] | [INFO] Results: | [INFO] | [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 | [INFO] | [INFO] ------------------------------------------------------ | [INFO] BUILD SUCCESS | [INFO] ------------------------------------------------------ | [INFO] Total time: 3.318 s | [INFO] Finished at: 2025-08-22T10:26:29Z | [INFO] ------------------------------------------------------ [workflow.yml/test] ✅ Success - Main Run "fast" tests [20.920776212s] [workflow.yml/test] ⭐ Run Post Setup JDK [workflow.yml/test] 🐳 docker exec cmd=[/opt/acttoolcache/node/18.20.8/x64/bin/node /var/run/act/actions/actions-setup-java@v4/dist/cleanup/index.js] user= workdir= | [command]/usr/bin/tar --posix -cf cache.tzst --exclude cache.tzst -P -C /Users/nico/projects/act-sample --files-from manifest.txt --use-compress-program zstdmt | Cache Size: ~50 MB (52701753 B) | Cache saved successfully | Cache saved with the key: setup-java-Linux-x64-maven-ef0e54e9035c18b60db7ea0af5e2f0c4cc5445dd6a2a2a672b91e14f14e7e4c2 [workflow.yml/test] ✅ Success - Post Setup JDK [1.01412383s] [workflow.yml/test] ⭐ Run Complete job [workflow.yml/test] Cleaning up container for job test [workflow.yml/test] ✅ Success - Complete job [workflow.yml/test] 🏁 Job succeeded ฉันสามารถเขียนสองโพสต์เกี่ยวกับ ; ฉันจะปล่อยให้คุณอ่านเอกสาร act Tip: เพื่อลดเวลารอบการตอบสนองของคุณ Test your workflows locally คําอธิบาย ใช้คําอธิบายที่ถูกต้องให้แตกต่างระหว่างกระบวนการทํางานและกระบวนการ เลือก GitHub Actions มากกว่าคําสั่ง ad-hoc ให้ความระมัดระวังในการเลือกการกระทํา GitHub เช่นเดียวกับการเลือกการพึ่งพาอื่น ๆ อ่านอย่างระมัดระวังเอกสารของแต่ละขั้นตอนที่คุณใช้ การกระทํา Pin ไปยัง commit ที่เฉพาะเจาะจง ใช้สรุปงาน GitHub เพื่อปรับปรุงประสบการณ์สําหรับนักพัฒนา เรียนรู้วงจรชีวิตของกระบวนการทํางาน ตรวจสอบกระบวนการทํางานของคุณในท้องถิ่น To go further: เกี่ยวกับ Workflows GitHub การกระทํา GitHub ตลาดการกระทํา Runner รูปภาพ เพิ่มสรุปงาน ฟังก์ชั่นการตรวจสอบสถานะ การแนะนําให้กระทํา