D3「撰寫與維護 actions」14 題原創模擬題，附正確答案、解析與常見陷阱。選項順序在互動版會隨機排列。
團隊同時使用 Ubuntu、Windows 與 macOS 的 GitHub 代管 runner，要寫一個呼叫 REST API 並整理結果的 action。哪種類型適合？
單選題，選項：
正確答案：JavaScript action，三種作業系統都能執行
解析：JavaScript action 可以跑在 Linux、macOS 與 Windows；Docker 容器 action 只能在 Linux runner 執行。
常見陷阱：Docker 看起來能跨平台，但容器 action 在 macOS 與 Windows 的 GitHub 代管 runner 上無法執行；跨平台需求先排除它。
Docker 容器 action 可以在 GitHub 代管的 Windows runner 上執行。
是非題：判斷敘述是否正確。
正確答案：錯誤
解析：Docker 容器 action 只能在 Linux runner 執行；自管 runner 若要使用，也要先安裝 Docker。
常見陷阱：容器技術常被當成跨平台的方案；這裡的限制是 runner 的作業系統，不是映像本身。
同事把 node_modules 提交進 JavaScript action 的 repository，說這樣使用者不用另外安裝。比較好的做法是什麼？
單選題，選項：
正確答案：用 rollup.js 或 @vercel/ncc 打包成單一檔案並提交
解析：官方說提交 node_modules 可能造成問題；改用 rollup.js 或 @vercel/ncc 把程式碼與相依套件打包成 dist/index.js 並提交，main 指向它。
常見陷阱：「不提交相依套件」與「要求使用者安裝」都不符合 action 的使用方式，使用者只會用 uses 呼叫；要提交的是打包後的單一檔案。
複合 action 的某個步驟寫了 run: ./cleanup.sh，被判定為無效。最可能缺少什麼？
單選題，選項：
正確答案：在該步驟指定 shell，例如 bash
解析：複合 action 中有 run 的步驟必須同時設定 shell。
常見陷阱：一般工作流程的 run 步驟可以省略 shell 而使用預設值；複合 action 的 run 沒有這個預設，必須明確指定。
JavaScript action 在 action.yml 的 runs.using 要設成 node20 或 node24 這類 Node.js 版本。
是非題：判斷敘述是否正確。
正確答案：正確
解析：JavaScript action 的 runs.using 值是 node20 或 node24，main 必填並指向要執行的檔案。
常見陷阱：容易把它與 Docker 的 'docker' 或複合的 'composite' 混淆；三種類型的 runs.using 各有固定值。
JavaScript action 同時定義了 pre 與 post，沒有另外設定 pre-if 或 post-if。它們預設在什麼條件下執行？
單選題，選項：
正確答案：always()，依 job 的狀態評估
解析：pre-if 與 post-if 預設都是 always()，其中的狀態檢查函式依 job 的狀態評估，不是 action 自己的狀態。
常見陷阱：post 常被用來清理，直覺上以為只在成功時才跑；預設其實是不論結果都跑，而且狀態是依 job 評估，不是依 action 自己。
複合 action 宣告了輸出 result，但沒有 value，呼叫端拿不到值。應該怎麼修？
單選題，選項：
正確答案：替輸出補上 value，指向某個步驟的輸出
解析：複合 action 的輸出必須有 value，指向步驟的輸出，例如 steps.calc.outputs.result；該步驟要有 id 並寫入 GITHUB_OUTPUT。
常見陷阱：JavaScript 與 Docker action 的輸出只需要 description，沒有 value；規則因 action 類型而異。
action 中繼資料檔的頂層，哪些鍵是必填？（選 3 項）
複選題，選項：
正確答案：name，action 的名稱；description，簡短的說明；runs，執行方式的設定
解析：頂層必填的鍵是 name、description、runs；author 與 inputs 是選填。
常見陷阱：author 看起來像基本資料而容易被當成必填；官方把它列為選填。
準備發佈到 GitHub Marketplace 的 repository，中繼資料檔應該怎麼放？
單選題，選項：
正確答案：根目錄只放一個 action.yml 或 action.yaml
解析：要發佈到 Marketplace，根目錄只能有一個 action 中繼資料檔；子資料夾裡的檔案可以使用，但不會被 Marketplace 自動列出。
常見陷阱：monorepo 習慣把每個元件放在子資料夾；這種配置能用，但無法一個 repository 發佈多個 Marketplace action。
輸入 token 設了 required: true，使用者沒有傳值，action 卻照常執行，到後面才出錯。為什麼？
單選題，選項：
正確答案：required: true 不會自動報錯，action 要自己檢查輸入
解析：required: true 並不會在缺值時自動報錯，action 必須自己檢查輸入，必要時用 core.setFailed 結束。
常見陷阱：欄位名稱看起來像驗證規則，卻只是描述性的標記；缺值的處理要寫在 action 的程式裡。
要讓同一組織的其他 repository 使用放在私有 repository 的 action，應該在哪裡設定？
單選題，選項：
正確答案：該 repository 的 Settings → Actions → General → Access
解析：在私有 repository 的 Settings → Actions → General → Access 開放給其他 repository；runner 以範圍受限、一小時後過期的安裝權杖下載。
常見陷阱：Marketplace 只接受公開 repository；私有 repository 的 action 要走存取設定，而且要注意外部協作者也可能間接取得存取。
符合所有條件並發佈 action 到 GitHub Marketplace 時，GitHub 會怎麼處理？
單選題，選項：
正確答案：立即發佈，GitHub 不會先審核
解析：符合條件時 action 會立即發佈，GitHub 不會先審核。
常見陷阱：應用程式商店常見人工審核流程；Marketplace 的 action 沒有發佈前的審核，信任要靠使用者自己評估。
你剛發佈 action 的 v1.4.0 release，要讓釘在 v1 的使用者取得新版，又不被破壞性變更影響。應該怎麼做？
單選題，選項：
正確答案：把 v1 與 v1.4 標籤移到這個相容的 commit
解析：用語意化版本標籤建立 release，並讓主版本標籤 v1 與次版本標籤 v1.4 指向最新且相容的 commit；破壞性變更才發 v2。
常見陷阱：主版本標籤是給使用者「自動取得相容更新」的指標，相容時要移動它；刪除或改發 v2 會讓使用者無法自動取得。
組織啟用 immutable releases 後，發佈流程用強制推送移動 v1 標籤失敗。原因是什麼？
單選題，選項：
正確答案：release 的標籤被鎖定在特定 commit，不能移動
解析：immutable release 發佈後，標籤鎖定在特定 commit，不能移動，且 release 存在時不能刪除；因此不能再用強制推送移動綁定 release 的標籤。
常見陷阱：失敗看起來像權限或簽章問題；原因是標籤本身被鎖定，需要調整版本策略，例如讓使用者釘到具體標籤或 SHA。