12:55 Carol: 我啟動清除檔案的 Job，整個裝置的容量還是不太夠，該怎麼辦啊
12:30 Alice: 垃圾筒也看過了？
12:33 Carol: ……對，我也想不到法子了，就算調高執行 Job 的頻率，也跟不上檔案建立的速度啊
12:39 Bos: 為什麼一直爆容量啊 ?

前篇提到因為 Jenkins 機器的容量常常佔比太高，所以建立清除檔案的 Job，也調整頻率，但問題還是發生。那還有什麼方向可以去解決呢？先前提到清楚檔案的 Job，先檢查這些 command 是否可以有效執行，先確保既有的指令是正常的。

上述都沒問題之後，可以往哪些方向，先回到 Android 發版的流程裡哪一步是進行包版，首先來複習包版有兩種指令：

### APK 檔案
./gardlew assamble
### AAB 檔案
./gradlew bundleDebug

檢查執令都正常執行，執行的內容是也可以順利包版。

上述的指令，若是只有使用預設 Android 專案的 debug 或 relese 就沒有問題，若目前執行的專案有使用多個 product flavor 的話，不妨去看看包版只需指定特定的 product flavor 即可。舉 assamble 來說，會建立所有 product flavor 底下的 APK。想想如果你的 product flavor 有三種環境，可能每個環境底下還有假設還有對應的內容，像是分成不同成員可以使用，或是不同的外部廠商或客戶。又再建立不同的 product flavor 維度，光是下一個 assmable 指令就會是 3 * N * M 個 APK，一個 APK 若是 30MB 的話，每一次 ./gradlew assamble 會變成 3 * N * M * 30MB。

接下來可以怎麼改善呢？確認 Job 要執行的發佈環境指定特定的 product flavor，讓每個 Job 在執行包版只會產生一個 APK，降低每一次執行時會產生的檔案個數。

來做個回小結，在遇到 Job 的狀況，可以如何檢視自己的腳本：

1. 確認每一個指令都可以正常執行
2. 回顧自己的開發流程，找尋可能會產生問題點
3. 改善後，再回頭檢視是否問題不會再發生