GitHub Actions со SHA без застој: Dependabot го ажурира заклучениот commit

|Автор: Уредувачки тим на QUASA|4 мин. читање
GitHub Actions со SHA без застој: Dependabot го ажурира заклучениот commit

За да заклучите надворешна GitHub Action, заменете ја верзиската ознака по uses со целосен commit SHA од официјалното складиште на action. Според безбедносните насоки на GitHub, тоа е начинот action да се користи како непроменливо издание: ознаката може да се премести или избрише. SHA ја фиксира ревизијата, но пред копирање треба да се провери дека потекнува од вистинското складиште, а не од fork.

За да не ги барате новите верзии рачно, додадете .github/dependabot.yml за екосистемот github-actions. Упатството на GitHub за Dependabot предвидува проверка на workflow-датотеките со directory: "/" и неделен распоред; кога ќе најде застарена action, Dependabot отвора pull request. Предложениот SHA станува дел од workflow дури по спојувањето на промената.

Проверете од каде потекнува SHA

Почнете од името на складиштето во постојната референца, на пример actions/checkout. Отворете го изданието во тоа складиште, следете ја врската од верзиската ознака до commit и копирајте го целиот SHA. Во примерот, commit во складиштето actions/checkout е 3d3c42e5aac5ba805825da76410c181273ba90b1 и ја подготвува верзијата v7.0.1.

Проверете дали адресата на commit ја содржи истата комбинација од сопственик и складиште како референцата во uses. Потоа споредете го commit со оној на избраното издание. Краткиот SHA што се прикажува во преглед не е доволен за заклучување; во workflow внесете ја целата вредност. Ако користите друга action, земете SHA од нејзиното складиште, бидејќи вредноста од овој пример важи само за actions/checkout.

Проверката на потеклото е важна и кога на друго место ќе најдете готов ред за копирање. Коментарот со верзија во туѓ workflow може да биде застарен или погрешен, а commit од fork не го докажува потеклото што го очекувате. Фиксирана референца гарантира дека ќе се побара истиот commit; таа сама по себе не кажува дали кодот во него е соодветен за вашиот проект.

Внесете ја фиксираната референца во workflow

Следниов условен пример е целосна содржина за .github/workflows/sha-check.yml. При push го презема кодот со избраниот commit на actions/checkout и извршува едноставна команда. Коментарот на редот со uses ја задржува читливата верзија; ревизијата што се извршува ја одредува SHA по знакот @.

name: Проверка со SHA

on: [push]

permissions:

  contents: read

jobs:

  verify:

    runs-on: ubuntu-latest

    steps:

      - name: Преземи го кодот

        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

      - name: Провери го преземениот код

        run: git status --short

Зачувајте ги YAML-вовлекувањата при пренесување на примерот во датотека. Поставката contents: read му дава на токенот пристап за читање на содржината што му е потребна на оваа задача. Командата git status --short е само едноставен чекор по преземањето на кодот; таа не го проверува потеклото на action. Ако подоцна рачно го смените SHA, проверете го и коментарот: промена само на коментарот не го менува кодот што се извршува.

Вклучете неделни предлози од Dependabot

Создајте .github/dependabot.yml со конфигурацијата подолу. Ако веќе имате таква датотека за други зависности, додадете ја ставката за github-actions во постојната листа updates. Вредноста directory: "/" го насочува Dependabot кон workflow-датотеките во .github/workflows; таму не се внесува патеката до поединечен workflow.

version: 2

updates:

  - package-ecosystem: "github-actions"

    directory: "/"

    schedule:

      interval: "weekly"

По зачувувањето на конфигурацијата, Dependabot проверува дали користените actions имаат понови верзии и предлага промени преку pull requests. Неделниот распоред означува зачестеност на проверката, а не ветување дека секоја недела ќе има нов предлог. За да може да ја ажурира референцата, action треба да биде наведена со GitHub синтакса како actions/checkout@...; локалните actions наведени со релативна патека не влегуваат во овој механизам.

Прегледајте го предлогот пред спојување

Во pull request од Dependabot споредете ги новиот SHA, верзискиот коментар и складиштето на action. Кога коментарот е на истиот ред со референцата, Dependabot може да ја ажурира и таа читлива ознака. Сепак, проверете дали новиот commit припаѓа на очекуваното складиште и на изданието што сакате да го користите, па прегледајте ги промените и резултатите од workflow-проверките пред спојување.

Ако почетниот commit нема поврзана ознака, Dependabot може да предложи најнов commit што се разликува од последното објавено издание. Во таков случај проверката на commit и неговите промени е особено важна. Заклучувањето на SHA спречува незабележано поместување на референцата, додека pull request го прави преминот кон нов код видлив и предмет на одлука од тимот. За actions заклучени на SHA, предупредувањата на Dependabot за ранливи actions имаат посебно ограничување: не се создаваат за тие референци, па предлозите за верзиски ажурирања не треба да се мешаат со такви предупредувања.

Прочитајте и:

Сподели:

Претплатете се на нашиот билтен

Добивајте ги најновите вести за Web3, AI и крипто директно во вашето сандаче.

0