Dependabot odottaa kolme päivää – tutkimus suosii usein seitsemää

Kun Dependabotin versiopäivitykset ovat käytössä, uusi pakettiversio joutuu oletuksena odottamaan kolme päivää julkaisustaan ennen kuin sitä harkitaan päivitykseen. GitHubin cooldown-ohje rajaa viiveen versiopäivityksiin: se ei koske Dependabotin tietoturvapäivityksiä. Odotusaikaa muutetaan repositorion .github/dependabot.yml-tiedoston cooldown-asetuksella.

Seitsemän päivän yleinen viive on harkittava valinta, jos tavallisten päivitysehdotusten ei tarvitse seurata aivan tuoretta julkaisua. Vuonna 2026 julkaistussa avoimen lähdekoodin tutkimuksessa seitsemän päivää oli valinta 157:ssä niistä 244 ekosysteemistä, joissa yleinen viive oli määritetty, eli 64,3 prosentissa. Aineisto kuvaa ylläpitäjien asetuksia ennen GitHubin nykyistä oletusviivettä; yleinen valinta ei ole mitattu turvallisuusraja.

Mistä odotusaika lasketaan?

Cooldown lasketaan uuden pakettiversion julkaisuhetkestä. Dependabot tarkistaa versiopäivityksiä erillisen schedule.interval-asetuksen tahdissa ja sivuuttaa tarkistuksessa version, jonka odotusaika on kesken. Kun aika on kulunut, versio voidaan ottaa mukaan seuraavaan tarkistukseen. Seitsemän päivän asetus ei siksi tarkoita, että pull request syntyisi juuri seitsemäntenä päivänä.

Jos tarkistuksia tehdään harvoin, odotusaika ja tarkistusten väli kasautuvat. Viikoittaisella tarkistuksella juuri tarkistuksen jälkeen julkaistu versio voi ehtiä cooldownin yli vasta seuraavaa tarkistusta myöhemmälle kierrokselle. Asetus siis määrää version aikaisimman harkintahetken, ei päivitysehdotuksen toimituspäivää. Tämä ero auttaa valitsemaan viiveen ilman, että koko versiopäivitysten tarkistusrytmiä täytyy hidastaa.

Valmis asetus kolmelle päivitystasolle

Tallenna seuraava esimerkki repositorion oletushaaraan nimellä .github/dependabot.yml. Se seuraa juurihakemiston npm-riippuvuuksia arkipäivisin ja antaa korjaus-, sivu- ja pääversioille eri odotusajat. Vaihda package-ecosystem ja directory, jos projektin paketinhallinta tai manifestien sijainti on toinen. GitHubin asetusviite määrittelee nämä avaimet, niiden etusijajärjestyksen ja tuetut ekosysteemit.

version: 2

updates:

  - package-ecosystem: "npm"

    directory: "/"

    schedule:

      interval: "daily"

    cooldown:

      default-days: 7

      semver-major-days: 30

      semver-minor-days: 7

      semver-patch-days: 3

Esimerkin riskijako on ylläpitäjän valinta: korjausversio odottaa kolme päivää, sivuversio seitsemän ja pääversio 30 päivää. default-days antaa yleisen viiveen päivityksille, joille erillinen SemVer-arvo ei sovellu. Se toimii myös varalla, jos jokin tasokohtainen arvo jätetään pois. Tutkimuksen yleinen seitsemän päivän valinta ei yksin perustele esimerkin pidempää pääversioviivettä.

Asetus interval: "daily" tarkoittaa Dependabotissa tarkistusta arkipäivisin, ei keskeytymätöntä seurantaa. Jos paketti julkaistaan ennen viikonloppua, cooldown voi päättyä viikonloppuna mutta päivitysehdotus odottaa seuraavaa ajastettua tarkistusta. Sama mekanismi selittää, miksi eri repositoriot voivat saada samasta julkaisuajasta erilaisen pull requestin ajankohdan, vaikka niiden cooldown olisi yhtä pitkä.

Milloin seitsemän päivää kannattaa valita?

Seitsemän päivän yleinen viive sopii lähtökohdaksi, kun tavallisen päivityksen kiireellisyys on pieni ja ylläpitäjä haluaa antaa uudelle julkaisulle aikaa ennen automaattista ehdotusta. Odotuksen aikana mahdollinen virheellinen tai haitallinen julkaisu voi tulla ilmi tai poistua jakelusta. Cooldown ei kuitenkaan tarkasta paketin sisältöä eikä takaa, että ongelma havaitaan valitun ajan kuluessa.

Lyhyempi odotus voi palvella riippuvuutta, jonka tuoreet korjausversiot halutaan arvioida nopeasti. Pidempi aika voi olla perusteltu pääversion muutokselle, jos päivitys vaatii yhteensopivuustyötä ja tavallisia pääversioehdotuksia kertyy paljon. Nämä ovat projektikohtaisia ylläpitopäätöksiä: viiveen pituus kannattaa suhteuttaa siihen, kuinka pian ehdotus voidaan tosiasiassa tarkistaa ja yhdistää.

Yhden yleisen arvon etu on yksinkertaisuus. Tasokohtaisia aikoja tarvitaan vasta, kun niiden erolle on selvä syy. Jos ylläpitäjä vaihtaa esimerkin kaikki tasokohtaiset rivit pelkkään default-days-arvoon, sama odotus koskee kaikkia kyseisen määrityksen versiopäivityksiä. Tällöin sääntöä on helppo ylläpitää, mutta kiireettömän pääversiomuutoksen ja nopeasti tarvittavan korjausversion välille ei jää eroa.

Miten include, exclude ja SemVer rajaavat viivettä?

Esimerkissä ei ole include-listaa, joten cooldown koskee kaikkia kyseisen npm-määrityksen riippuvuuksia. Jos viive halutaan rajata nimettyihin paketteihin, cooldown-lohkoon voi lisätä include-listan; tähtimerkki toimii nimimallissa jokerimerkkinä. Kun lähes kaikkien pakettien halutaan odottavan, yleinen sääntö ja lyhyt exclude-lista ovat usein selkeämpi yhdistelmä kuin jatkuvasti täydennettävä include-lista.

Exclude ohittaa include-säännön, jos sama paketti täsmää molempiin. Cooldown ei silloin pidätä kyseisen paketin tavallista versiopäivitystä, mutta päivitysehdotus seuraa edelleen tarkistusaikataulua. Exclude on eri asia kuin ignore: ensimmäinen poistaa odotusajan, jälkimmäisellä voidaan rajata päivityksiä pois. Nämä kaksi asetusta ratkaisevat siis eri kysymykset, vaikka niiden kohteena olisi sama riippuvuus.

SemVer-avaimet toimivat vain paketinhallinnoissa, joille GitHub ilmoittaa tasokohtaisen tuen. npm kuuluu niihin, mutta kaikkien ekosysteemien kohdalla tasoja ei voi käyttää. Pelkkä default-days on laajemmin tuettu vaihtoehto. Cooldown ei myöskään muuta manifestin versiorajoja tai versioning-strategy-asetusta: odotusajan päättyminen tekee versiosta harkittavan, minkä jälkeen muut päivityssäännöt ratkaisevat ehdotuksen sisällön.

Miksi tietoturvakorjaus voi edetä odottamatta?

Dependabotin tietoturvapäivitys kulkee eri polkua kuin tavallinen versiopäivitys, joten cooldown ei lisää siihen odotusaikaa. Jos haavoittuva riippuvuus tarvitsee korjaavan version, tietoturvapäivityksen pull request voi syntyä saman paketin tavallisen versiopäivityksen vielä odottaessa. Tietoturvapäivitysten on oltava repositoriossa käytössä, jotta Dependabot voi tehdä tällaisia ehdotuksia; pelkkä yllä oleva versiopäivitysten YAML ei ota niitä käyttöön.

Raja on hyödyllinen juuri silloin, kun ylläpitäjä haluaa hidastaa tuoreiden julkaisujen tavanomaista käyttöönottoa mutta käsitellä tunnetun haavoittuvuuden ripeästi. Myös tietoturvapäivitys tarvitsee normaalin katselmoinnin ja testit ennen yhdistämistä. Cooldown säätelee ehdotuksen ajoitusta; päätös ottaa uusi pakettiversio käyttöön jää repositorion ylläpidolle.

Lue myös:

• GitHubin tietoturvakorjaus muistaa vanhat ratkaisut – tieto säilyy 28 päivää
• Later tuo YouTube-datan kampanjoihin – 30 päivää aliarvioi tulosta
• NotebookLM vai ChatGPT PDF-tutkimukseen? Rajattu aineisto vähentää arvailua