Mwongozo wa vitendo kwa ajili ya kujenga GitHub workflows smart

Nina uzoefu wa muda mrefu sana na mtiririko wa kazi wa GitHub, lakini si kwa kiwango ambacho ninaweza kusema mimi ni mtaalamu. Hata hivyo, hivi karibuni nilianzisha mtiririko mpya wa kazi, na nilifuatilia kuandika chapisho hili. Njia ya kazi ya GitHub ni nini? Mchakato wa kazi ni mchakato wa automatiska unaoweza kurekebishwa ambao utaendesha kazi moja au zaidi. Mchakato wa kazi unafafanuliwa na faili ya YAML iliyosajiliwa kwenye hifadhi yako na utaendeshwa wakati unaofanywa na tukio katika hifadhi yako, au inaweza kufanywa kwa manually au kwa muda uliopangwa. Mzunguko wa kazi unafafanuliwa katika orodha ya .github/mzunguko wa kazi katika uhifadhi. Uhifadhi unaweza kuwa na mzunguko wa kazi kadhaa, ambayo kila mmoja anaweza kutekeleza seti tofauti ya kazi, kama vile: Kujenga na kujaribu maombi ya Pull Kuweka maombi yako kila wakati uwasilishaji unaundwa Kuongeza alama kila wakati suala jipya linapofunguliwa Kuhusu Mipango ya kazi Mchakato wa kazi ni mchakato wa automatiska unaoweza kurekebishwa ambao utaendesha kazi moja au zaidi. Mchakato wa kazi unafafanuliwa na faili ya YAML iliyosajiliwa kwenye hifadhi yako na utaendeshwa wakati unaofanywa na tukio katika hifadhi yako, au inaweza kufanywa kwa manually au kwa muda uliopangwa. Mchakato wa kazi unaoelezwa katika Uhifadhi unaweza kuwa na mtiririko wa kazi kadhaa, ambayo kila moja inaweza kutekeleza seti tofauti ya kazi, kama vile: .github/workflows Kujenga na kujaribu maombi ya Pull Kuweka maombi yako kila wakati uwasilishaji unaundwa Kuongeza alama kila wakati suala jipya linapofunguliwa Kuhusu Mipango ya kazi Kwa hiyo, mchakato wa kazi unaweza kulinganishwa na kazi ya Jenkins, iliyoandaliwa katika YAML badala ya XML. Hata hivyo, tofauti kuu ni kwamba muundo wa mchakato wa kazi ni , kinyume na muundo wa kazi wa Jenkins wa urithi. Haionekani kama mengi, lakini inaruhusu kutumia mbinu za usimamizi wa chanzo, ikiwa ni pamoja na versioning na rolling nyuma. Miaka iliyopita, nilifanya kazi kwa mteja ambaye timu ya DevOps ilitumia mbinu ya msingi ya Puppet ili kurekebisha kazi ya Jenkins ili muundo wa Puppet unaweza kuhifadhiwa katika Git. Ilikuwa jitihada kubwa! stored inside the code repository Kumbuka kwamba GitHub ilikuwa nyuma sana kwa chama. Kabla ya kutekeleza mtiririko wa kazi, nilitumia huduma ya tatu inayoitwa Niliibadilisha hasa kwa sababu Travis ilipokea malipo na kwa upande mwingine kwa sababu harakati za kazi ni sehemu ya asili ya GitHub. Maana ya Kiwango hiki: Wao ni kuitwa Hatua za GitHub ni tofauti kabisa. Use the correct semantics Mipango ya GitHub Utaratibu wa GitHub Mzunguko wa kazi wa GitHub unajumuisha ambao ni pamoja na Hatua ya Maelezo amri, na vigezo vichache vya chaguzi, ikiwa ni pamoja na jina. Kazi ya Hatua ya Kuendesha jobs: metrics: runs-on: my-image #1 steps: - name: Install dependencies via Poetry #2 run: poetry install #3 Picha ya OCI ambayo mchakato wa kazi unaendesha Jina la hatua Amri ya hatua Hatua za GitHub ni vipengele vinavyoweza kutumika tena ambavyo hutoa mbadala za kurudia amri hiyo mara kwa mara. Hatua ni seti iliyopangwa, inaweza kutumika tena ya kazi au code ambayo inafanya kazi maalum ndani ya mzunguko wa kazi, kupunguza kiasi cha mzunguko wa code unayoandika katika faili zako za mzunguko wa kazi. Kuondoa hifadhi yako ya Git kutoka GitHub Kujenga toolchain sahihi kwa mazingira yako ya kujenga Kujenga uhakiki kwa mtoa huduma wako wa wingu Unaweza kuandika vitendo vyako mwenyewe, au unaweza kupata vitendo vya kutumia katika mzunguko wako wa kazi katika GitHub Marketplace. Kwa mfano, badala ya kutekeleza git checkout, unaweza kutumia hatua ya checkout. Utaratibu wa GitHub ya ni seti iliyopangwa, inaweza kutumika tena ya kazi au code ambayo inafanya kazi maalum ndani ya , kupunguza kiasi cha msimbo wa kurudia unaandika kwenye faili zako za mzunguko wa kazi. vitendo vinaweza kutekeleza kazi kama vile: action workflow Kuondoa hifadhi yako ya Git kutoka GitHub Kujenga toolchain sahihi kwa mazingira yako ya kujenga Kujenga uhakiki kwa mtoa huduma wako wa wingu Unaweza kuandika vitendo vyako mwenyewe, au unaweza kupata vitendo vya kutumia katika mtiririko wako wa kazi katika Kwa mfano, badala ya kufanya Kwa hiyo, unaweza kutumia . Soko la GitHub git checkout Hatua ya Checkout Utaratibu wa GitHub jobs: metrics: runs-on: my-image steps: - uses: actions/checkout@v5 #1 with: #2 fetch-depth: 0 submodules: recursive Maelezo ya GitHub Action Utaratibu wa hatua Mimi ni mtazamaji mkubwa wa kutojenga upya rangi. GitHub Action ina jukumu kubwa katika hilo. Kiwango hiki: wakati inawezekana Prefer GitHub Actions over ad-hoc commands Kuchagua hatua sahihi Maonyesho ya GitHub Marketplace Hatua zinaonyeshwa kwa makundi. Unaweza kupima kwa aina ya mtengenezaji na kutengeneza kwa umaarufu. mengi ya vitendo Wakati wa kuchagua hatua, unapaswa kutumia tahadhari sawa kama wakati wa kuleta viungo vingine. Hapa ni vigezo vichache ili kukusaidia: 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 Kiwango hiki: Be as careful in choosing a GitHub Action as in choosing any other dependency. Kujua matendo yako Kama ushauri wa awali, hii inatokana na moja ya kawaida zaidi—Ninaongea kutokana na uzoefu. Mimi nilijenga mchakato wa kazi ili kuunganisha programu ya Java. Mimi nilitumia kwa kiasi kikubwa mchakato wa kazi, na kazi ilihitaji kupakua mahusiano wakati wote. 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 Kuweka JDK Weka cache. cache ni ya kawaida na inaweza cache faili kwa njia ya kuendesha. Kuhifadhi hifadhi ya ndani ya Maven Kichwa hutumia OS ya runner, ambayo haibadilika, na hash ya POM. Kwa hiyo, hatua huunda cache mpya kila wakati POM inabadilika. Hata hivyo, kwa kusoma nyaraka, nilielewa kwamba ningeweza kufikia sawa kwa njia rahisi zaidi: Hatua hii ina utendaji wa ndani kwa ajili ya kuhifadhi na kurejesha mahusiano. Inatumia toolkit/cache chini ya hood kwa ajili ya kuhifadhi mahusiano lakini inahitaji mipangilio madogo ya usanidi. Msimamizi wa pakiti unaotumika ni gradle, maven na sbt. Aina ya kifungo cha cache kilichotumika ni setup-java-${{platform }}-${{ packageManager }}-${ fileHash }}, ambapo hash inategemea faili zifuatazo: Maudhui ya Maven: */pom.xml Kuhifadhi vifaa vya kujitegemea Hatua hii ina utendaji wa ndani kwa ajili ya caching na kurejesha mahusiano. Inatumia toolkit / cache chini ya hood kwa ajili ya caching mahusiano lakini inahitaji mipangilio madogo ya usanidi. Msimamizi wa pakiti unaotumika ni gradle, maven na sbt. ambapo hash inategemea faili zifuatazo: setup-java-${{ platform }}-${{ packageManager }}-${{ fileHash }} Maudhui ya Maven: */pom.xml Kuhifadhi vifaa vya kujitegemea Kwa hiyo, nimebadili kipande cha juu na kama ifuatavyo: 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 Huu ndio Kiwango hiki: Kutumia saa moja kwenye nyaraka inaweza kukusaidia kuokoa siku za kazi. Thoroughly read the documentation of actions. Pina toleo lako la kujitegemea Sehemu hii pia inachukua ushauri wa kawaida na inatumika kwa toleo la GitHub workflows. Unaweza kupata toleo katika angalau maeneo mawili: picha ya OCI na toleo la GitHub Actions. Unaweza kuwa umeona kwamba katika vipindi vya awali.Kwa wakati wa kuandika hii, inaonyesha kwamba Baada ya muda, itaonyesha toleo la hivi karibuni, na toleo la maktaba tofauti. Inaweza kusababisha kushindwa wakati wa uendeshaji wa mtiririko wa kazi, au mbaya zaidi, kubadilisha output kwa njia ambazo huwezi kugundua mpaka ni baadaye sana. [Mfano wa picha zote zilizopo] runs-on: ubuntu-latest ubuntu-24.04 https://github.com/actions/runner-images Tathmini ya matendo inafanya kazi tofauti, kwa sababu zinaonyesha maelekezo ya repo ya GitHub: au tag au commit SHA. Wakati picha ya OCI iko mikononi mwa GitHub, hatua ni jukumu la mtoa huduma wake. Hii inamaanisha mtu yeyote mwenye haki ya commit anaweza kubadilisha maudhui ya tag ya msingi. Pina kwa ajili ya commit. must jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@08c6903 #1 Pin kwa commit maalum 💡 Tip: Kuchukua usalama kwa umakini na pin actions to a specific commit. Tumia muhtasari wa kazi Kila moja ya hatua zako za mchakato wa kazi huenda hutoa logs nyingi. Katika mchakato wa kazi wa kawaida, kiwango cha jumla cha mstari wa log inaweza kuwa kubwa sana. Baadhi yao inaweza kuwa na manufaa, baadhi yao inaweza kuwa hawana, lakini kwa sababu kuna tu output ya kiwango na makosa ya kiwango, kila kitu huishia mahali fulani. , idadi ya majaribio yanayotumika au asilimia ya umuhimu wa msimbo, ikiwa huna kutuma data hii mahali pengine. GitHub inafanya iwe rahisi kuongeza data unayotaka katika muhtasari wa kazi. ya G. Unaweza kutumia muhtasari wa kazi ili kuonyesha na kikundi maudhui ya kipekee, kama vile muhtasari wa matokeo ya mtihani, ili mtu anayeangalia matokeo ya uendeshaji wa mchakato wa kazi hauhitaji kwenda kwenye kumbukumbu ili kuona habari muhimu zinazohusiana na uendeshaji, kama vile kushindwa. Picha za kazi zinaunga mkono Markdown iliyotengenezwa na GitHub, na unaweza kuongeza maudhui yako ya Markdown kwa hatua moja kwenye faili ya mazingira ya GITHUB_STEP_SUMMARY. Kuongeza maelezo ya kazi Unaweza kutumia muhtasari wa kazi ili kuonyesha na kikundi maudhui ya kipekee, kama vile muhtasari wa matokeo ya mtihani, ili mtu anayeangalia matokeo ya uendeshaji wa mchakato wa kazi hauhitaji kwenda kwenye kumbukumbu ili kuona habari muhimu zinazohusiana na uendeshaji, kama vile kushindwa. Picha za kazi zinaunga mkono Markdown iliyotengenezwa na GitHub, na unaweza kuongeza maudhui yako ya Markdown kwa hatua moja kwenye faili ya mazingira ya GITHUB_STEP_SUMMARY. - ya Kuongeza maelezo ya kazi Hapa ni a Maelezo ya Apache Arrow: Mifano ya - 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 ya ni ya: Matokeo ya Kiwango hiki: kuimarisha uzoefu wa watengenezaji. Use GitHub job summary Kuelewa mzunguko wa maisha wa kazi Mchakato wa kazi unaendesha hatua kwa mfululizo. Hatua ya kushindwa huondoa hatua zingine zote, na mzunguko wa kazi unamalizika katika Katika mfano wa hapo juu, inamaanisha hatutapata maelezo yoyote ya mtihani hata kidogo ikiwa hatua yoyote inayofuata haifai. Hali ya Failure if Unaweza kutumia kazi za udhibiti wa hali zifuatazo kama maneno katika if conditionals. Utafiti wa hali ya default ya mafanikio() hutumika isipokuwa unajumuisha moja ya kazi hizi. • Ufuatiliaji wa utendaji kazi Unaweza kutumia kazi za udhibiti wa hali zifuatazo kama maneno katika if conditionals. Utafiti wa hali ya default ya mafanikio() hutumika isipokuwa unajumuisha moja ya kazi hizi. - ya Utafiti wa utendaji wa kazi Mtumiaji wa GitHub kwa default, lakini chaguzi ni pamoja na ya na ya . 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 Daima kuendesha hatua, bila kujali kama hatua za awali zilikuwa na mafanikio au sio Sasa fikiria mfululizo wafuatayo: - 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 Kuendesha majaribio ya kitengo pia hutoa ripoti za JUnit Tumia ripoti za JUnit zilizoundwa kuandika muhtasari wa hatua Ikiwa hatua ya kwanza haifai, hatua ya muhtasari inafanya kazi bila kujali kama majaribio yalikuwa yameendeshwa. Ikiwa hawakufanya, itakuwa kushindwa. Ili kuepuka hili, tunapaswa kufafanua hali zaidi ili hatua ya muhtasari inafanya kazi tu ikiwa hatua ya mtihani ya kipekee ilifanya. - 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 Tumia id ya hatua Kuendesha tu ikiwa hatua ya mtihani inaendesha kwa ufanisi Ni mfano rahisi tu, lakini inatoa chaguzi za kuvutia. Kiwango hiki: Tumia kwa faida yako. Know workflows' lifecycle Utafiti wa ndani Mamia ya mashirika ya kutekeleza sheria kali za GitHub. moja ya kuenea zaidi ni kwamba huwezi kushinikiza : kila ahadi inapaswa kwenda kupitia ombi la kuchukua. Ingawa ina maana kwa miradi iliyowekwa, inakadiriwa kuanza miradi kutoka iterating haraka wakati kuhifadhi historia ya ahadi. Katika muktadha wa kuendeleza kazi ya GitHub, ni dhahiri crippling. master Hapa inakuja mchakato wa sheria: “Tunafikiri kwa kiwango cha kimataifa na kutenda kwa kiwango cha ndani” Kuendesha vitendo vyako vya GitHub kwa ndani! Kwa nini ungependa kufanya hili? Sababu mbili: - 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 • Kuingia kwa vitendo “Tunafikiri kwa kiwango cha kimataifa na kutenda kwa kiwango cha ndani” Kuendesha vitendo vyako vya GitHub kwa ndani! Kwa nini ungependa kufanya hili? Sababu mbili: Maoni ya haraka - Badala ya kuwa na kufanya / kushinikiza kila wakati unataka kujaribu mabadiliko unayotengeneza kwenye faili zako za .github / workflows / (au kwa mabadiliko yoyote ya vitendo vya GitHub vinavyowekwa), unaweza kutumia hatua ili kuendesha vitendo vya ndani. variables ya mazingira na mfumo wa faili vyote vimewekwa kulingana na kile GitHub inatoa. Local Task Runner - Napenda kufanya. Hata hivyo, napenda pia kujaribu kurudia mwenyewe. Na hatua, unaweza kutumia hatua za GitHub zilizotajwa katika .github/workflows/ yako ili kubadilisha Makefile yako! - ya Utangulizi wa act ina ushirikiano wa GitHub CLI ambayo huchochea mtiririko wa kazi kulingana na tukio sahihi. act gh act push Hapa ni matokeo wakati picha na vitendo tayari zimeharibiwa: 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] ---- ----- | [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 Ninaweza kuandika machapisho machache juu ya Nitawaacha wewe kusoma nyaraka. act Kiwango hiki: Kupunguza muda wa mzunguko wako wa maoni. Test your workflows locally Muhtasari wa Tumia semantics sahihi, tofauti kati ya mzunguko wa kazi na vitendo. Kutoa maagizo ya GitHub juu ya maagizo ya ad-hoc. Kuwa makini sana katika kuchagua hatua ya GitHub kama katika kuchagua utegemezi wowote. Soma kwa makini nyaraka za kila hatua unayotumia. Pina hatua kwa ajili ya commit maalum. Tumia muhtasari wa kazi wa GitHub ili kuboresha uzoefu wa watengenezaji. Kujua mzunguko wa maisha wa workflow. Jaribu mzunguko wako wa kazi kwa ndani. To go further: Kuhusu mchakato wa kazi Kazi ya GitHub GitHub Soko la Uendeshaji Picha ya Runner Kuongeza maelezo ya kazi Utafiti wa utendaji wa kazi Maonyesho ya Act