â mjeti ynĂ« CLI GitOps me kod tĂ« hapur pĂ«r ndĂ«rtimin dhe dĂ«rgimin e aplikacioneve nĂ« Kubernetes. Ashtu siç e premtuam, shĂ«noi fillimin e shtimit tĂ« mundĂ«sive tĂ« reja nĂ« werf dhe rishikimin e qasjeve tĂ« zakonshme. Tani jemi tĂ« gĂ«zuar tĂ« paraqesim lĂ«shimin v1.1, i cili Ă«shtĂ« njĂ« hap i madh nĂ« zhvillim dhe njĂ« frymĂ«zim pĂ«r tĂ« ardhmen ndĂ«rtuesit werf. Versioni Ă«shtĂ« i disponueshĂ«m tani nĂ« .
Thelbi i lëshimit është arkitektura e re e magazinës për fazat dhe optimizimi i funksionimit të të dy ndërtuesve (për Stapel dhe Dockerfile). Arkitektura e re e magazinës hap mundësi për realizimin e ndërtimeve të shpërndara nga disa hostë dhe ndërtimeve paralele në një host.
Optimizimi i funksionimit përfshin heqjen e llogaritjeve të panevojshme në fazën e llogaritjes së nënshkrimeve të fazave dhe ndryshimin e mekanizmave të llogaritjes së kontrollit të shumave të skedarëve në më efikas. Kjo optimizim zvogëlon kohën mesatare të ndërtimeve të projektit duke përdorur werf. Edhe ndërtimet e zbrazta, kur të gjitha fazat ekzistojnë në cache stages-storage, tani janë vërtet të shpejta. Në shumicën e rasteve, rinisja e ndërtimit do të kalojë më shpejt se 1 sekondë! Kjo vlen gjithashtu për procedurat e verifikimit të fazave gjatë punës së ekipeve werf deploy dhe werf run.
Gjithashtu nĂ« kĂ«tĂ« lĂ«shim u shfaq strategjia e etiketimit tĂ« imazheve sipas pĂ«rmbajtjes â content-based tagging, e cila tani Ă«shtĂ« e aktivizuar si parazgjedhje dhe Ă«shtĂ« e vetmja e rekomanduar.
Le të shqyrtojmë më në detaje novitetet kryesore në werf v1.1, ndërsa gjithashtu do të flasim për planet për të ardhmen.
ĂfarĂ« ka ndryshuar nĂ« werf v1.1?
Formati i ri i emërtimit të fazave dhe algoritmi i përzgjedhjes së fazave nga cache
Rregulli i ri i gjenerimit të emrit të fazës. Tani çdo ndërtim faze gjeneron një emër unik të fazës, i cili përbëhet nga 2 pjesë: nënshkrimi (si ishte në v1.0) plus një identifikues të kohës unik.
Për shembull, emri i plotë i imazhit të fazës mund të duket kështu:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
⊠ose në formë të përgjithshme:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
KĂ«tu:
-
SIGNATUREâ Ă«shtĂ« nĂ«nshkrimi i fazĂ«s, i cili paraqet identifikuesin e pĂ«rmbajtjes sĂ« fazĂ«s dhe varet nga historia e ndryshimeve nĂ« Git, qĂ« solli kĂ«tĂ« pĂ«rmbajtje; -
TIMESTAMP_MILLISECâ Ă«shtĂ« njĂ« identifikues garantues unik i imazhit, i cili gjenerohet nĂ« momentin e ndĂ«rtimit tĂ« njĂ« imazhi tĂ« ri.
Algoritmi i përzgjedhjes së fazave nga cache bazohet në kontrollin e lidhshmërisë së Git-commit-ëve:
- Werf llogarit nënshkrimin e një faze të caktuar.
- Në stages-storage mund të ekzistojnë disa faza për këtë nënshkrim. Werf zgjedh të gjitha fazat që përputhen me nënshkrimin.
- Nëse faza aktuale është e lidhur me Git (git-archive, një fazë e përdoruesit me Git-patch:
instalo,paraSetup,setup; ose git-latest-patch), atĂ«herĂ« werf zgjedh vetĂ«m ato faza qĂ« janĂ« tĂ« lidhura me commit-in qĂ« Ă«shtĂ« paraardhĂ«si i commit-it aktual (pĂ«r tĂ« cilin Ă«shtĂ« thirrur ndĂ«rtimi). - Nga fazat e mbetura tĂ« pĂ«rshtatshme, zgjedhet njĂ« â ajo mĂ« e vjetĂ«r nĂ« datĂ«n e krijimit.
Faza për degë të ndryshme Git mund të ketë të njëjtin nënshkrim. Por werf do të parandalojë përdorimin e caches të lidhura me degë të ndryshme midis këtyre degëve, edhe nëse nënshkrimet përputhen.
.
Algoritmi i ri për krijimin dhe ruajtjen e fazave në magazinën e fazave
Nëse gjatë përzgjedhjes së fazave nga cache, werf nuk gjen një fazë të përshtatshme, atëherë aktivizohet procesi i ndërtimit të një faze të re.
VĂ«rejmĂ« se disa procese (nĂ« njĂ« ose disa hoste) mund tĂ« fillojnĂ« ndĂ«rtimin e tĂ« njĂ«jtĂ«s fazĂ« nĂ« mĂ«nyrĂ« tĂ« pĂ«rafĂ«rt nĂ« tĂ« njĂ«jtĂ«n kohĂ«. Werf pĂ«rdor algoritmin e bllokimit optimist stages-storage nĂ« momentin e ruajtjes sĂ« imazhit tĂ« sapo ndĂ«rtuar nĂ« stages-storage. KĂ«shtu, kur ndĂ«rtimi i njĂ« faze tĂ« re Ă«shtĂ« pĂ«rfunduar, werf bllokon stages-storage dhe ruan aty vetĂ«m imazhin e sapo ndĂ«rtuar nĂ« rast se atje nuk ekziston tashmĂ« njĂ« imazh i pĂ«rshtatshĂ«m (sipĂ«r nĂ«nshkrimit dhe parametrave tĂ« tjerĂ« â shihni algoritmin e ri tĂ« pĂ«rzgjedhjes sĂ« fazave nga cache).
Imazhi i sapo ndërtuar do të ketë me siguri një identifikues unik sipas TIMESTAMP_MILLISEC (shihni formatin e ri të emërimit të fazave). Në rast se në stages-storage do të gjendet një imazh i përshtatshëm, werf do të hedhë poshtë imazhin e sapo ndërtuar dhe do të përdorë imazhin nga cache.
Me fjalë të tjera: procesi i parë që përfundon ndërtimin e imazhit (më i shpejti), do të ketë të drejtat e ruajtjes në stages-storage (dhe vetëm ky imazh do të përdoret për të gjitha ndërtimet). Procesi i ngadaltë i ndërtimit nuk do ta bllokojë kurrë procesin më të shpejtë nga ruajtja e rezultateve të ndërtimit të fazës aktuale dhe kalimi në ndërtimin e fazës tjetër.
.
Përformanca e ndërtuesit të Dockerfile është përmirësuar
NĂ« kĂ«tĂ« moment, konstrukti i fazave pĂ«r imazhin e ndĂ«rtuar nga Dockerfile pĂ«rbĂ«het nga njĂ« fazĂ« â dockerfile. NĂ« llogaritjen e nĂ«nshkrimit llogaritet suma e kontrollet e skedarĂ«ve context, qĂ« do tĂ« pĂ«rdoren gjatĂ« ndĂ«rtimit. Para kĂ«tij pĂ«rmirĂ«simi, werf kalonte rekurzivisht nĂ«pĂ«r tĂ« gjithĂ« skedarĂ«t dhe merrte shumĂ«n e kontrollit duke pĂ«rmbledhur kontekstin dhe modin e çdo skedari. Duke filluar nga versionet v1.1, werf mund tĂ« pĂ«rdorĂ« shumĂ«n e kontrollet e llogaritur, tĂ« ruajtur nĂ« depo Git.
Në thelb të algoritmit është . Algoritmi merr parasysh të dhënat në .dockerignore dhe kalon rekurzivisht nëpër pemën e skedarëve vetëm kur është e nevojshme. Kështu, ne u çlirua nga leximi i sistemit të skedarëve, dhe varësia e algoritmit nga madhësia context nuk është e rëndësishme.
Po ashtu, algoritmi kontrollon skedarët e pa ndjekur dhe, kur është e nevojshme, i përfshin ata në shumën e kontrollit.
Përmirësuar performanca gjatë importimit të skedarëve
Në versionet werf v1.1 përdoret një server rsync gjatë . Më parë, importimi kryhej në dy hapa duke përdorur montimin e drejtorisë nga sistemi host.
Performanca e importeve në macOS nuk është më e kufizuar nga volumi Docker, dhe importet kryhen për të njëjtën kohë si në Linux dhe Windows.
Etiketa e bazuar në përmbajtje
Werf v1.1 mbĂ«shtet atĂ« qĂ« quhet etiketa e bazuar nĂ« pĂ«rmbajtjen e imazhit â content-based tagging. Etiketat e imazheve pĂ«rfundimtare Docker varen nga pĂ«rmbajtja e kĂ«tyre imazheve.
GjatĂ« ekzekutimit tĂ« komandĂ«s werf publish --tags-by-stages-signature ose werf ci-env --tagging-strategy=stages-signature do tĂ« etiketohen imazhet e publikuara me atĂ« qĂ« quhet nĂ«nshkrimi i fazave tĂ« imazhit. Ădo imazh etiketizohet me nĂ«nshkrimin e vet tĂ« fazave tĂ« kĂ«tij imazhi, i cili llogaritet sipas tĂ« njĂ«jtave rregulla si nĂ«nshkrimi normal i secilĂ«s fazĂ« veçmas, por Ă«shtĂ« njĂ« identifikues agregues i imazhit.
Nënshkrimi i fazave të imazhit varet nga:
- përmbajtja e këtij imazhi;
- historia e modifikimeve në Git, që çuan në këtë përmbajtje.
Në depo Git gjithmonë ka komitete të kota, që nuk ndryshojnë përmbajtjen e skedarëve të imazhit. Për shembull, komitete që kanë vetëm komente ose komitete bashkimit, ose komitete që ndryshojnë ato skedarë në Git, që nuk do të importohen në imazh.
Duke pĂ«rdorimi i tagging-ut tĂ« bazuar nĂ« pĂ«rmbajtje zgjidh problemet e rindezjes sĂ« panevojshme tĂ« podâĂ«ve tĂ« aplikacionit nĂ« Kubernetes pĂ«r shkak tĂ« ndryshimeve nĂ« emrin e imazhit, edhe nĂ«se pĂ«rmbajtja e imazhit nuk ka ndryshuar. PĂ«r mĂ« tepĂ«r, kjo Ă«shtĂ« njĂ« nga arsyet qĂ« pengojnĂ« ruajtjen e shumĂ« mikrosherbimeve tĂ« njĂ« aplikacioni nĂ« njĂ« Git-repozitor tĂ« vetĂ«m.
Gjithashtu, tagging-u i bazuar nĂ« pĂ«rmbajtje Ă«shtĂ« njĂ« metodĂ« mĂ« e besueshme pĂ«r tagging sesa tagging-u sipas degĂ«ve tĂ« Git, sepse pĂ«rmbajtja e imazheve pĂ«rfundimtare nuk varet nga rendi i ekzekutimit tĂ« pipelineâave nĂ« sistemin CI pĂ«r ndĂ«rtimin e disa komiteteve tĂ« tĂ« njĂ«jtĂ«s degĂ«.
ĂhtĂ« e rĂ«ndĂ«sishme: duke filluar nga ky moment stages-signature â Ă«shtĂ« strategjia e vetme e rekomanduar pĂ«r tagging. Ajo do tĂ« pĂ«rdoret si parazgjedhje nĂ« komandĂ«n werf ci-env (nĂ«se nuk especificohet njĂ« skemĂ« tjetĂ«r tagimi).
. KĂ«saj veçorie do t'i dedikohet gjithashtu njĂ« publikim tĂ« veçantĂ«. PĂRPUNUAR (3 Prill): Artikulli me detaje .
Nivelet e regjistrimit
Këtu, përdoruesi ka mundësinë të kontrollojë daljen, të caktuar nivelin e regjistrimit dhe të punojë me informacionin e debug-imit. Janë shtuar opsionet --log-quiet, --log-verbose, --log-debug.
Për parazgjedhje, në dalje përmban minimum informacioni:
Duke përdorur daljen e detajuar (--log-verbose) mund të ndjekësh se si punon werf:
Dalja e detajuar (--log-debug), përveç informacionit të debug-imit nga werf, gjithashtu përmban log-et e bibliotekave të përdorura. Për shembull, mund të shihni se si ndodh ndërveprimi me Docker Registry, si dhe të regjistroni vendet ku humb shumë kohë:
Planet e ardhshme
Kujdes! Funksionalitetet e pĂ«rshkruara mĂ« poshtĂ« me shenimin v1.1 do tĂ« bĂ«hen tĂ« aksesueshme qĂ« nĂ« kĂ«tĂ« version, shumĂ« nga to â nĂ« njĂ« tĂ« ardhme tĂ« afĂ«rt. PĂ«rditĂ«simet do tĂ« vijnĂ« pĂ«rmes autoazhgjerimeve . KĂ«to funksionalitete nuk prekin pjesĂ«n e stabilizuar tĂ« funksioneve v1.1, shfaqja e tyre nuk do tĂ« kĂ«rkojĂ« ndĂ«rhyrje manuale nga pĂ«rdoruesi nĂ« konfigurimet ekzistuese.
Përkrahje e plotë për realizime të ndryshme të Docker Registry (E RE)
- Versioni: v1.1
- Afatet: mars
Qëllimi është që përdoruesi të përdorë realizimin e tij të preferuar pa kufizime kur përdor werf.
Në këtë moment, ne kemi identifikuar grupin e mëposhtëm të zgjidhjeve për të cilat planifikojmë të ofrojmë mbështetje të plotë:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Me yllë kanë shënuar zgjidhjet që aktualisht mbështeten plotësisht nga werf. Për të tjerat ka mbështetje, por me kufizime.
Mund të veçojmë dy probleme kryesore:
- Disa zgjidhje nuk mbështesin fshirjen eetiketave me anë të Docker Registry API, gjë që nuk u lejon përdoruesve të përdorin pastrimin automatik të implementuar në werf. Ky fakt është valid për AWS ECR, Docker Hub dhe GitHub Packages.
- Një pjesë e zgjidhjeve nuk mbështesin, ashtuquajturat, nested repositories (Docker Hub, GitHub Packages dhe Quay) ose mbështesin, por përdoruesi duhet t'i krijojë ato manualisht duke përdorur UI ose API (AWS ECR).
Ne synojmë të zgjidhim këto e probleme të tjera duke përdorur API-të native të zgjidhjeve. Ky projekt përfshin gjithashtu mbulimin me teste të ciklit të plotë të funksionimit të werf për secilën prej tyre.
NdĂ«rtime tĂ« shpĂ«rndara tĂ« imazheve (â)
- Versioni: v1.2 v1.1 (prioriteti për implementimin e kësaj mundësie është rritur)
- Afatet: mars-prill mars
Aktualisht, werf v1.0 dhe v1.1 mund të përdoren vetëm në një host të dedikuar për operacionet e ndërtimit, botimit të imazheve dhe vendosjes së aplikacionit në Kubernetes.
Për të hapur mundësitë e punës shpërndare të werf, kur ndërtimi dhe vendosja e aplikacioneve në Kubernetes fillojnë në disa host-e të rastësishme dhe këta host-e nuk ruajnë gjendjen e tyre midis ndërtimeve (runner të përkohshëm), werf kërkon zbatimin e mundësisë për të përdorur Docker Registry si depo të stadeve.
Më parë, kur projekti werf quhej dapp, ekzistonte një mundësi e tillë. Sidoqoftë, ne përballëm disa probleme që duhet të merret parasysh gjatë implementimit të kësaj funksionaliteti në werf.
Shënim. Kjo mundësi nuk parashikon punë të ndërtuesit brenda pod-eve të Kubernetes, sepse për këtë duhet të hiqet varësia nga serveri lokal Docker (në pod-in e Kubernetes nuk ka akses në serverin lokal Docker, sepse vetë procesi është i lansuar në një kontenier, dhe werf nuk mbështet dhe nuk do të mbështesë punën me serverin Docker në rrjet). Mbështetje për punën në Kubernetes do të realizohet ndaras.
Mbështetje zyrtare për GitHub Actions (E RE)
- Versioni: v1.1
- Afatet: mars
Përfshin dokumentacionin e werf (seksionet referencë dhe udhëzues), si dhe një veprim të zyrtarizuar të GitHub për të punuar me werf.
Për më tepër, kjo do të lejojë që werf të punojë në runner të efemer.
Mekanika e ndërveprimit të përdoruesit me sistemin CI do të bazohet në vendosjen e etiketimeve mbi kërkesat për bashkim për të nismuar veprime të caktuara për ndërtimin/dërgimin e aplikacionit.
Zhvillimi lokal dhe disfatimi i aplikacioneve me werf (â)
- Versioni: v1.1
- Afatet: janar-shkurt prill
Qëllimi kryesor është të arrihet një konfigurim i unifikuar për disfatimin e aplikacioneve si lokal, ashtu edhe në prodhim, pa veprime të komplikuara, "nga kutia".
Nga werf kërkohet gjithashtu një mod operativ ku do të jetë e rehatshme të redaktohet kodi i aplikacionit dhe të marrim menjëherë reagim nga aplikacioni funksional për debug.
Algoritmi i ri i pastrimit (E RE)
- Versioni: v1.1
- Afatet: prill
NĂ« versionin aktual tĂ« werf v1.1 nĂ« procedurĂ«n cleanup nuk Ă«shtĂ« parashikuar pastrimi i imazheve pĂ«r skemĂ«n e etiketimit bazuar nĂ« pĂ«rmbajtje (content-based tagging) â kĂ«to imazhe do tĂ« grumbullohen.
Gjithashtu, në versionin aktual të werf (v1.0 dhe v1.1) përdoren politika të ndryshme pastrimi për imazhet e publikuara sipas skemave të etiketimit: degë Git, etiketë Git ose angazhim Git.
ĂshtĂ« menduar njĂ« algoritĂ«m i ri unifikues pĂ«r tĂ« gjitha skemat e etiketimit pĂ«r pastrimin e imazheve duke u bazuar nĂ« historinĂ« e angazhimeve nĂ« Git:
- Të ruhet jo më shumë se N1 imazhe të lidhura me N2 angazhimet e fundit për secilën nga git HEAD (degat dhe etiketat).
- Të ruhet jo më shumë se N1 imazhe-stage, të lidhura me N2 angazhimet e fundit për secilën nga git HEAD (degat dhe etiketat).
- Të ruhet gjithë imazhet që përdoren në burimet e klasterit Kubernetes (shkanohet të gjithë kube-kontekste të skedës së konfigurimit dhe hapësirat emërore; mund të kufizohet kjo sjellje me opsione të veçanta).
- Të ruhet gjithë imazhet që përdoren në manifestet e konfigurimit të burimeve, të ruajtura në lëshimet Helm.
- Një imazh mund të fshihet nëse nuk është i lidhur me asnjë HEAD nga git (p.sh., sepse ai lidhës përkatës është fshirë) dhe nuk përdoret në asnjë nga manifestet në klasterin Kubernetes dhe në lëshimet Helm.
NdĂ«rtimi paralel i imazheve (â)
- Versioni: v1.1
- Afatet: janar-shkurt prill*
Versioni aktual i werf ndĂ«rtan imazhet dhe artefaktet e pĂ«rshkruara nĂ« werf.yamlkĂ«shtu, gradualisht. ĂshtĂ« e nevojshme tĂ« paralelizohet procesi i ndĂ«rtimit tĂ« indivitĂ«ve tĂ« pavarur tĂ« imazheve dhe artefakteve, si dhe tĂ« sigurohet njĂ« output i pĂ«rshtatshĂ«m dhe informativ.
* Shënim: afati është shtyrë për shkak të rritjes së prioritetit për zbatimin e ndarjes së shpërndarë, e cila do të shtojë më shumë mundësi për shkallëzimin horizontal dhe përdorimin e werf me GitHub Actions. Ndërsa ndarja paralele është hapi tjetër i optimizimit, duke ofruar shkallëzim vertikal gjatë ndarjes së një projekti.
Kalimi nĂ« Helm 3 (â)
- Versioni: v1.2
- Afatet: shkurt-mars maj*
Përfshin kalimin në bazën e re të kodit dhe një mënyrë të provuar dhe të lehtë për migrimin e instalimeve ekzistuese.
* Shënim: kalimi në Helm 3 nuk do të sjellë mundësi të rëndësishme në werf, sepse të gjitha funksionalitetet kryesore të Helm 3 (3-way-merge dhe mungesa e tiller) janë tashmë të zbatuara në werf. Për më tepër, werf ka përveç atyre të përmendura. Sidoqoftë, ky kalim mbetet në planet tona dhe do të realizohet.
Jsonnet pĂ«r pĂ«rshkrimin e konfiguracionit Kubernetes (â)
- Versioni: v1.2
- Afatet: janar-shkurt prill-maj
Werf do të mbështesë përshkrimin e konfiguracionit për Kubernetes në formatin Jsonnet. Në të njëjtën kohë, werf do të mbetet në përputhje me Helm dhe do të ketë mundësinë e zgjedhjes së formatit të përshkrimit.
Shkaku është se shabllonet e gjuhës Go, sipas vlerësimit të shumë njerëzve, kanë një prag të lartë hyrjeje, dhe kuptueshmëria e kodit të këtyre shablloneve gjithashtu vuante.
Po ashtu, po shqyrtohet mundësia e implementimit të sistemeve të tjera përshkruese të konfiguracionit Kubernetes (për shembull, Kustomize).
Puna brenda Kubernetes (â)
- Versioni: v1.2
- Afatet: prill-maj maj-qershor
Qëllimi: të sigurohet ndarja e imazheve dhe dorëzimi i aplikacionit duke përdorur runner në Kubernetes. Domethënë, ndarja e imazheve të reja, publikimi i tyre, pastrimi dhe deploy mund të ndodhin direkt nga pod Kubernetes.
Për të realizuar këtë mundësi, fillimisht kërkohet mundësia e ndarjes së shpërndarë të imazheve (shih pikën më lart).
Po ashtu kërkohet mbështetje për modin e punës së ndarësit pa serverin Docker (dmth, ndarje e ngjashme me Kaniko ose ndarje në userspace).
Werf do të mbështesë ndarjen në Kubernetes jo vetëm me Dockerfile, por gjithashtu me ndarësin e tij Stapel me ripërpunime inkrementale dhe Ansible.
Hapi drejt zhvillimit të hapur
Ne e duam komunitetin tonë (, ) dhe duam që gjithnjë e më shumë njerëz të ndihmojnë në përmirësimin e werf, të kuptojnë drejtimin në të cilin po lëvizim dhe të kontribuojnë në zhvillim.
Kohët e fundit u vendos që të kalojmë në për të hapur pak nga procesi i punës së ekipit tonë. Tani mund të shihni planet e afërta, si dhe punët aktuale në drejtimet e mëposhtme:
- ;
- ;
- ;
- .
K është bërë një punë e madhe me issues:
- Janë fshirë ato që nuk janë më të rëndësishme.
- Ato ekzistuese janë zvogëluar në një format të unifikuar, me numër të mjaftueshëm detajesh dhe hollësish.
- Janë shtuar issues të reja me ide dhe propozime.
Si të aktivizoni versionin v1.1
Versioni është i disponueshëm tani në (në kanalet stabil dhe shkëmbim të fortë lëshimet do të shfaqen me kalimin e kohës, megjithatë ea veta është e mjaftueshme e stabilizuar për përdorim, sepse ka kaluar përmes kanaleve alpha dhe beta). Aktivizohet në këtë mënyrë:
source $(multiwerf use 1.1 ea)
werf KOMANDA ...PĂ«rfundim
Arkitektura e re e ruajtjes së fazave dhe optimizimi i funksionimit të ndërtuesit për ndërtuesit Stapel dhe Dockerfile ofron mundësi për të realizuar ndërtime të shpërndara dhe paralel në werf. këto mundësi do të kenë shumë shpejt në të njëjtin lëshim v1.1 dhe do të bëhen automatikisht të disponueshme përmes mekanizmit të azhurnimeve automatik. ).
NĂ« kĂ«tĂ« lĂ«shim u shtua strategjia e etiketimit tĂ« pĂ«rmbajtjes sĂ« imazheve â content-based tagging, â e cila u bĂ« strategjia e paracaktuar. Gjithashtu u rishikua logu i komandave kryesore: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Hapi i ardhshëm i rëndësishëm do të jetë shtimi i ndërtimeve të shpërndara. Ndërtimet e shpërndara, nga versioni v1.0, janë bërë një prioritet më i lartë se ndërtimet paralel, sepse shtojnë më shumë vlerë për werf: shkallëzimi vertikal i ndërtuesve dhe mbështetje për ndërtuesit efemerë në sistemet e ndryshme CI/CD, si dhe mundësia për të bërë mbështetje zyrtare për GitHub Actions. Prandaj, afatet për realizimin e ndërtimeve paralel janë shtyrë. Megjithatë, ne po punojmë për t'i realizuar të dyja mundësitë sa më shpejt të jetë e mundur.
Mbani sytë hapur! Dhe mos harroni të shihni tek ne në , për të krijuar issue, për të gjetur një të ekzistueshëm dhe për të dhënë një plus, për të krijuar një PR ose thjesht për të ndjekur zhvillimin e projektit.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»
- «»;
- Cikli i shënimeve të rinovimeve në werf:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
