Methiannau mewn systemau adeiladu oherwydd newidiadau mewn symiau gwirio archif ar GitHub

Newidiodd GitHub y ffordd y mae'n cynhyrchu archifau β€œ.tar.gz” a β€œ.tgz” a gynhyrchir yn awtomatig ar dudalennau rhyddhau, a arweiniodd at newid yn eu sieciau a methiannau enfawr mewn systemau adeiladu awtomataidd sy'n gwirio archifau a lawrlwythwyd o GitHub yn erbyn rhai blaenorol i'w cadarnhau checksums wedi'u storio, er enghraifft, eu gosod mewn metadata pecyn neu mewn sgriptiau adeiladu.

Gan ddechrau gyda rhyddhau 2.38, roedd pecyn cymorth Git yn cynnwys gweithrediad integredig o gzip yn ddiofyn, a oedd yn ei gwneud hi'n bosibl uno cefnogaeth ar gyfer y dull cywasgu hwn ar draws systemau gweithredu a gwella perfformiad creu archifau. Cododd GitHub y newid ar Γ΄l diweddaru'r fersiwn o git yn ei seilwaith. Achoswyd y broblem gan y ffaith bod yr archifau cywasgedig a gynhyrchir gan weithrediad gzip adeiledig yn seiliedig ar zlib yn ddeuaidd yn wahanol i'r archifau a grΓ«wyd gan y cyfleustodau gzip, a arweiniodd at wahanol wiriadau ar gyfer archifau a grΓ«wyd gan wahanol fersiynau o git wrth weithredu'r gorchymyn "git archive".

Yn unol Γ’ hynny, ar Γ΄l diweddaru git yn GitHub, dechreuwyd arddangos archifau ychydig yn wahanol ar y tudalennau rhyddhau, nad oeddent yn pasio dilysiad gan ddefnyddio'r hen sieciau. Amlygodd y broblem ei hun mewn amrywiol systemau adeiladu, systemau integreiddio parhaus, ac offer ar gyfer adeiladu pecynnau o god ffynhonnell. Er enghraifft, torrwyd y cynulliad o tua 5800 o borthladdoedd FreeBSD, y cafodd y codau ffynhonnell eu lawrlwytho o GitHub.

Mewn ymateb i gwynion cychwynnol am y diffygion, cyfeiriodd GitHub at y ffaith nad oedd symiau gwirio parhaol ar gyfer archifau erioed wedi'u gwarantu. Ar Γ΄l dangos y byddai angen llawer iawn o waith i ddiweddaru'r metadata mewn amrywiol ecosystemau i adfer ymarferoldeb y systemau adeiladu yr effeithir arnynt, newidiodd cynrychiolwyr GitHub eu meddyliau, dychwelodd y newid a dychwelodd yr hen ddull o gynhyrchu archifau.

Nid yw datblygwyr Git wedi dod i benderfyniad eto a dim ond camau gweithredu posibl y maent yn eu trafod. Roedd yr opsiynau a ystyriwyd yn cynnwys dychwelyd i ddefnyddio'r cyfleustodau gzip rhagosodedig; ychwanegu'r faner β€œ--stabl” i gynnal cydnawsedd Γ’ hen archifau; cysylltu'r gweithredu adeiledig Γ’ fformat archif ar wahΓ’n; defnyddio'r cyfleustodau gzip ar gyfer hen ymrwymo a'r gweithredu mewnol ar gyfer ymrwymiadau yn dechrau o ddyddiad penodol; gwarantu sefydlogrwydd fformat yn unig ar gyfer archifau anghywasgedig.

Eglurir yr anhawster o wneud penderfyniad gan y ffaith nad yw dychwelyd i alwad i gyfleustodau allanol yn datrys y broblem o ansymudedd siec yn llwyr, oherwydd gall newid yn y rhaglen gzip allanol hefyd arwain at newid yn y fformat archif. Ar hyn o bryd, mae set o glytiau wedi'u cynnig i'w hadolygu sy'n dychwelyd yr hen ymddygiad yn ddiofyn (yn galw cyfleustodau gzip allanol) ac yn defnyddio'r gweithrediad adeiledig yn absenoldeb cyfleustodau gzip yn y system. Mae'r clytiau hefyd yn ychwanegu at y ddogfennaeth sΓ΄n nad yw sefydlogrwydd yr allbwn "git archive" wedi'i warantu ac y gallai'r fformat newid yn y dyfodol.

Ffynhonnell: opennet.ru

Ychwanegu sylw