GitHub Actions-ийг tag-аар бүү түгж: бүтэн SHA л хувилбарыг хөдөлгөөнгүй болгоно

GitHub Actions workflow-ийн uses: мөр дэх tag эсвэл branch-ийг хөдөлгөөнгүй болгохын тулд эх репозитороос нь шалгасан бүтэн commit SHA-аар соль. GitHub-ийн аюулгүй ашиглалтын заавар нь workflow dependency lockfile-ийг илүү өргөн хамгаалалт гэж үздэг ч uses: холбоосыг файл дотор SHA-аар түгжихдээ commit эх репозиторт харьяалагдахыг шалгахыг зөвлөдөг. Tag болон branch өөр commit руу шилжиж болно; бүтэн SHA нь сонгосон commit-ийг заасаар байна.

Шилжүүлэлтийн дараалал нь uses: холбоос бүрийг олох, сонгосон release-ийн commit-ийг баталгаажуулах, SHA-г мөрөнд бичих, хувилбарын нэрийг тайлбарт үлдээх, улмаар шинэчлэл санал болгох хэрэгсэл тохируулах юм. SHA-д түгжсэн action шинэ release рүү өөрөө шилжихгүй. Тиймээс кодын хувилбарыг тогтвортой хадгалах болон шинэчлэлээ алдахгүй байх ажлыг хамтад нь төлөвлө.

Workflow доторх uses: холбоос бүрийг ол

Репозиторын үндсэн сангаас git grep -n 'uses:' -- .github/workflows командыг ажиллуулж, Git-д бүртгэлтэй workflow файлуудын таарсан мөр, байршлыг гарга. Үр дүнгийн мөр бүрийг нээж шалга: uses: нь алхамд ашиглах action, job түвшинд дуудах дахин ашиглах workflow, эсвэл ердөө тайлбарын текст байж болно. Бүх таарцыг нэг загвараар бөөнөөр солих нь эдгээр ялгааг алдагдуулна.

Алсын action ихэвчлэн OWNER/REPO@REF хэлбэртэй. Харин ./.github/actions/... гэж эхэлсэн зам нь тухайн репозиторын локал action тул түүнд алсын репозиторын SHA хайх шаардлагагүй. Job түвшний uses: мөрийг тусад нь тэмдэглэ: дахин ашиглах workflow-г дуудах холбоос болон түүний дотор ажиллах action-уудыг өөр өөр газарт шалгана.

Бүртгэлдээ action-ийн нэр, одоогийн tag эсвэл branch, эх репозитор, ашиглаж буй workflow, сонгох release-ээ бич. Нэг action олон файлд орсон бол хувилбарууд нь зориуд ялгаатай эсэхийг эхлээд тогтоо. Алсын дахин ашиглах workflow дотроо action дууддаг бол тэдгээр uses: мөр дуудагч репозиторын хайлтад харагдахгүй; workflow байрладаг репозиторыг мөн хамруул.

SHA-г эх репозитортой нь тулга

OWNER/REPO нэрээр action-ийн эх репозиторыг нээж, хэрэглэх release tag ямар commit руу зааж байгааг тогтоо. Тэр commit-ийн бүтэн SHA-г авч, commit эх репозиторын түүхэнд байгааг шалга. Ижил нэртэй fork, хайлтын үр дүн дэх хэш эсвэл гуравдагч этгээдийн бэлдсэн жагсаалт нь энэ тулгалтыг орлохгүй.

Сонгосон tag, түүнд харгалзах commit, workflow-д бичих SHA гурав хоорондоо таарах ёстой. Үүний дараа тухайн commit дээрх action-ийн код болон өмнө ашиглаж байсан хувилбараас орсон өөрчлөлтийг хар. SHA нь сонгосон кодыг тогтмол заадаг болохоос код өөрөө аюулгүй гэсэн баталгаа биш. Action нууц мэдээлэл эсвэл GITHUB_TOKEN ашигладаг бол тэдгээрийг хэрхэн уншиж, дамжуулж байгааг хяна.

Эцсийн diff-ийг нэгтгэхийн өмнө хэшээ эх репозитор дахь commit-той дахин тулга. Release tag хожим өөр commit руу шилжсэн ч workflow-д бичсэн SHA түүнийг дагаж өөрчлөгдөхгүй. Энэ нь хянагчид ажиллуулах кодын холбоосыг release-ийн уншихад хялбар нэрээс тусад нь баталгаажуулах боломж өгнө.

uses: мөрийг сольж, хувилбарын нэрийг хадгал

Шалгасан SHA-г @ тэмдгийн дараа бүтнээр нь оруул. Нөхцөлт загвар нь uses: OWNER/REPO@FULL_COMMIT_SHA # vX.Y.Z; FULL_COMMIT_SHA болон vX.Y.Z-ийг эх репозиторт тулгасан бодит утгаар соль. Ижил мөрийн # тайлбар нь сонгосон release-ийг хүнд ойлгуулна, харин @ тэмдгийн дараах SHA нь ажиллуулах commit-ийг тогтооно.

Өөрчлөлтийн хүсэлтэд хуучин болон шинэ uses: мөр, сонгосон release, хэш авсан эх репозиторыг тэмдэглэ. Хянагч action-ийн нэр хэвээр байгаа, SHA бүтэн, тайлбар дахь хувилбар зөв commit-той таарч байгааг diff-ээс харах ёстой. Дараа нь workflow-ийн ердийн шалгалтыг ажиллуул: шинэ commit action-ийн оролт, гаралт эсвэл шаардах зөвшөөрлийг өөрчилсөн бол зөв SHA сонгосон ч workflow-д тохируулга хэрэг болж болно.

Байгууллагын хэмжээнд шаардлага болго

Олон репозиторт хэрэгжүүлэхдээ action холбоосуудаа засаж, төлөөлөх хэдэн репозиторт шалгасны дараа байгууллагын шаардлагыг идэвхжүүл. Semgrep-ийн байгууллагын түвшний хэрэгжүүлэлтийн тайлбар нь Require actions to be pinned to a full-length commit SHA тохиргоо болон tag, branch, дам action-ийн холбоосыг шалгах хэрэгцээг өгүүлдэг. Тэнд дурдсан tj-actions/changed-files-ийн халдлагад release tag-уудыг хортой commit руу шилжүүлсэн нь tag-аар заасан workflow яагаад өөр код татаж болдгийн бодит жишээ юм.

Бодлогыг асаахаас өмнө action-ийн дотор дуудагдах бусад action-ийг ч шалга. Шууд дуудах action SHA-тай байсан ч дотроо tag-аар заасан хамааралтай бол workflow ажиллах үед шаардлагад бүдэрч болно. Дахин ашиглах workflow-г tag-аар дуудах холбоосыг энэ тохиргоо зөвшөөрдөг тул job түвшний uses: мөрийг тусад нь хянаж, тухайн workflow доторх action-уудыг мөн шалгах хэрэгтэй.

Байгууллагын бодлогыг шилжүүлэлтийн эхэнд асаавал засагдаагүй uses: холбоостой workflow ажиллахгүй. Эхлээд илэрсэн холбоосуудаа ангилж, туршилтаар ажиллуулсан репозиторт шаардлагыг асаан, гарсан алдааг зас. Үүний дараа үлдсэн репозиторт ижил дарааллыг хэрэглэж, байгууллагын түвшний шаардлагыг идэвхжүүлэх нь ажлын урсгалыг тасалдуулах эрсдэлийг багасгана.

Шинэчлэл санал болгох автоматжуулалт тохируул

SHA-д түгжсэн action-д шинэ release гарлаа гээд workflow-ийн хэш өөрөө солигдохгүй. GitHub-ийн Dependabot-ийн тохиргооны заавар нь .github/dependabot.yml файлд package-ecosystem: "github-actions", directory: "/" болон schedule.interval утга оруулахыг заадаг. Жишээлбэл, interval: "weekly" гэж тохируулбал Dependabot шинэ хувилбарыг тогтмол шалгаж, хуучирсан action-д pull request санал болгоно.

Renovate ашигладаг баг SHA-д түгжсэн GitHub Actions-ийн шинэчлэлийг мөн түүнд даатгаж болно. Аль хэрэгслийг сонгосон ч pull request ирэхэд хэш солигдсоныг дангаар нь зөвшөөрөх үндэслэл болгохгүй. Шинэ commit эх репозиторт байгаа эсэх, хувилбарын тайлбар түүнтэй таарч байгаа эсэх, release-ийн өөрчлөлт workflow-ийн оролт ба зөвшөөрөлд нөлөөлөх эсэхийг шалга.

Шилжүүлэлт дууссаныг дараах зүйлсээр шалга: алсын action бүрийн uses: мөр бүтэн SHA-тай, хэш нь эх репозиторт батлагдсан, ижил мөрөнд ойлгомжтой хувилбарын тайлбар үлдсэн, workflow шинэ commit-тэй ажилласан, байгууллагын шаардлага болон шинэчлэл санал болгох тохиргоо хэрэгжсэн. Шинэ action нэмэх эсвэл шинэ commit санал болгосон pull request ирэх бүрд эх репозитор, хэш, кодын өөрчлөлтийг дахин хяна.

Мөн уншаарай:

• GitHub Actions-д AWS key хадгалах хэрэггүй: OIDC-г нөхцөлтэй холбо
• GitHub Actions эсвэл GitLab CI: ижил pipeline 91 секундээр зөржээ
• mold 3.0 Rust-д бүрэн шилжив: C++ хувилбарын үе дууслаа