yw ein cyfleustodau ffynhonnell agored GitOps CLI ar gyfer adeiladu a chyflwyno ceisiadau i Kubernetes. Fel yr addawyd, yn nodi dechrau ychwanegu nodweddion newydd i werff ac adolygu dulliau traddodiadol. Nawr rydym yn falch o gyflwyno datganiad v1.1, sy'n gam mawr mewn datblygiad ac yn sylfaen ar gyfer y dyfodol casglwr werff. Mae'r fersiwn ar gael ar hyn o bryd yn .
Sail y datganiad yw pensaernïaeth newydd storio llwyfan ac optimeiddio gwaith y ddau gasglwr (ar gyfer Stapel a Dockerfile). Mae'r bensaernïaeth storio newydd yn agor y posibilrwydd o weithredu cynulliadau dosbarthedig o westeion lluosog a chynulliadau cyfochrog ar yr un gwesteiwr.
Mae optimeiddio gwaith yn cynnwys cael gwared ar gyfrifiadau diangen ar y cam o gyfrifo llofnodion cam a newid y mecanweithiau ar gyfer cyfrifo symiau gwirio ffeiliau i rai mwy effeithlon. Mae'r optimeiddio hwn yn lleihau amser cyfartalog adeiladu prosiectau gan ddefnyddio werff. Ac adeiladau segur, pan fydd pob cam yn bodoli yn y storfa camau-storio, yn awr yn gyflym iawn. Yn y rhan fwyaf o achosion, bydd ailgychwyn y gwaith adeiladu yn cymryd llai nag 1 eiliad! Mae hyn hefyd yn berthnasol i weithdrefnau ar gyfer dilysu camau yn y broses o waith timau. werf deploy и werf run.
Hefyd yn y datganiad hwn, ymddangosodd strategaeth ar gyfer tagio delweddau yn ôl cynnwys - tagio sy'n seiliedig ar gynnwys, sydd bellach wedi'i alluogi yn ddiofyn a'r unig un a argymhellir.
Gadewch i ni edrych yn agosach ar y datblygiadau arloesol allweddol yn werf v1.1, ac ar yr un pryd dweud wrthych am gynlluniau ar gyfer y dyfodol.
Beth sydd wedi newid yn werf v1.1?
Fformat enwi llwyfan newydd ac algorithm ar gyfer dewis camau o'r storfa
Rheol cynhyrchu enwau llwyfan newydd. Nawr mae pob cam adeiladu yn cynhyrchu enw llwyfan unigryw, sy'n cynnwys 2 ran: llofnod (fel yr oedd yn v1.0) ynghyd â dynodwr dros dro unigryw.
Er enghraifft, efallai y bydd enw delwedd y cam llawn yn edrych fel hyn:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...neu yn gyffredinol:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Yma:
-
SIGNATUREyn llofnod llwyfan, sy'n cynrychioli dynodwr cynnwys y llwyfan ac yn dibynnu ar hanes y golygiadau yn Git a arweiniodd at y cynnwys hwn; -
TIMESTAMP_MILLISECyn ddynodwr delwedd unigryw gwarantedig sy'n cael ei gynhyrchu ar yr adeg y caiff delwedd newydd ei hadeiladu.
Mae'r algorithm ar gyfer dewis camau o'r storfa yn seiliedig ar wirio perthynas Git yn ymrwymo:
- Mae Werf yn cyfrifo llofnod cam penodol.
- В camau-storio Gall fod sawl cam ar gyfer llofnod penodol. Mae Werf yn dewis pob cam sy'n cyfateb i'r llofnod.
- Os yw'r cam presennol yn gysylltiedig â Git (git-archive, cam arferol gyda chlytiau Git:
install,beforeSetup,setup; neu git-latest-patch), yna mae werf ond yn dewis y camau hynny sy'n gysylltiedig ag ymrwymiad sy'n gyndad i'r ymrwymiad presennol (y gelwir yr adeilad ar ei gyfer). - O'r camau addas sy'n weddill, dewisir un - yr hynaf erbyn dyddiad creu.
Gall llwyfan ar gyfer gwahanol ganghennau Git gael yr un llofnod. Ond bydd werff yn atal y storfa sy'n gysylltiedig â gwahanol ganghennau rhag cael ei ddefnyddio rhwng y canghennau hyn, hyd yn oed os yw'r llofnodion yn cyfateb.
.
Algorithm newydd ar gyfer creu ac arbed camau yn y storfa lwyfan
Os, wrth ddewis camau o'r storfa, nad yw werff yn dod o hyd i gam addas, yna mae'r broses o gydosod cam newydd yn cychwyn.
Sylwch y gall prosesau lluosog (ar un neu fwy o westeion) ddechrau adeiladu'r un cam tua'r un amser. Mae Werf yn defnyddio algorithm blocio optimistaidd camau-storio ar hyn o bryd o achub y ddelwedd a gasglwyd yn ffres i mewn camau-storio. Fel hyn, pan fydd y llwyfan adeiladu newydd yn barod, werff blociau camau-storio ac yn arbed delwedd a gasglwyd yn ffres yno dim ond os nad yw delwedd addas yn bodoli yno mwyach (trwy lofnod a pharamedrau eraill - gweler yr algorithm newydd ar gyfer dewis camau o'r storfa).
Mae delwedd newydd ei chasglu yn sicr o gael dynodwr unigryw erbyn TIMESTAMP_MILLISEC (gweler y fformat enwi llwyfan newydd). Rhag ofn yn camau-storio bydd delwedd addas yn cael ei chanfod, bydd werf yn taflu'r ddelwedd newydd ei llunio ac yn defnyddio'r ddelwedd o'r celc.
Mewn geiriau eraill: bydd y broses gyntaf i orffen adeiladu'r ddelwedd (yr un gyflymaf) yn cael yr hawl i'w storio fesul cam (ac yna'r ddelwedd sengl hon a ddefnyddir ar gyfer pob adeilad). Ni fydd proses adeiladu araf byth yn rhwystro proses gyflymach rhag arbed canlyniadau adeiladu'r cam presennol a symud ymlaen i'r adeilad nesaf.
.
Gwell perfformiad adeiladwr Dockerfile
Ar hyn o bryd, mae'r llinell o gamau ar gyfer delwedd a adeiladwyd o Dockerfile yn cynnwys un cam - dockerfile. Wrth gyfrifo'r llofnod, cyfrifir siec y ffeiliau context, a ddefnyddir yn ystod y cynulliad. Cyn y gwelliant hwn, cerddodd werf yn gyson trwy'r holl ffeiliau a chael siec trwy grynhoi cyd-destun a modd pob ffeil. Gan ddechrau gyda v1.1, gall werf ddefnyddio sieciau wedi'u cyfrifo sydd wedi'u storio mewn ystorfa Git.
Mae'r algorithm yn seiliedig ar . Mae'r algorithm yn cymryd i ystyriaeth cofnodion yn .dockerignore ac yn croesi'r goeden ffeil yn gyson dim ond pan fo angen. Felly, rydym wedi datgysylltu oddi wrth ddarllen y system ffeiliau, a dibyniaeth yr algorithm ar y maint context ddim yn arwyddocaol.
Mae'r algorithm hefyd yn gwirio ffeiliau heb eu tracio ac, os oes angen, yn eu cymryd i ystyriaeth yn y siec.
Gwell perfformiad wrth fewnforio ffeiliau
Mae fersiynau o werf v1.1 yn defnyddio gweinydd rsync pan . Yn flaenorol, gwnaed mewnforio mewn dau gam gan ddefnyddio mownt cyfeiriadur o'r system westeiwr.
Nid yw perfformiad mewnforio ar macOS bellach wedi'i gyfyngu gan gyfeintiau Docker, ac mae mewnforion yn cwblhau yn yr un faint o amser â Linux a Windows.
Tagio yn seiliedig ar gynnwys
Mae Werf v1.1 yn cefnogi'r hyn a elwir yn dagio yn ôl cynnwys delwedd - tagio sy'n seiliedig ar gynnwys. Mae tagiau'r delweddau Docker dilynol yn dibynnu ar gynnwys y delweddau hynny.
Wrth redeg y gorchymyn werf publish --tags-by-stages-signature neu werf ci-env --tagging-strategy=stages-signature delweddau cyhoeddedig o'r hyn a elwir llofnod llwyfan delwedd. Mae pob delwedd wedi'i dagio â'i lofnod ei hun o gamau'r ddelwedd hon, a gyfrifir yn unol â'r un rheolau â llofnod rheolaidd pob cam ar wahân, ond mae'n ddynodwr cyffredinol o'r ddelwedd.
Mae llofnod y camau delwedd yn dibynnu ar:
- cynnwys y ddelwedd hon;
- hanes y newidiadau Git a arweiniodd at y cynnwys hwn.
Mae gan ystorfa Git bob amser ymrwymiadau ffug nad ydynt yn newid cynnwys y ffeiliau delwedd. Er enghraifft, ymrwymo gyda sylwadau yn unig neu uno ymrwymiadau, neu ymrwymo sy'n newid y ffeiliau hynny yn Git na fydd yn cael eu mewnforio i'r ddelwedd.
Wrth ddefnyddio tagio sy'n seiliedig ar gynnwys, mae'r problemau o ailgychwyn codennau cais yn Kubernetes yn ddiangen oherwydd newidiadau yn enw'r ddelwedd yn cael eu datrys, hyd yn oed os nad yw cynnwys y ddelwedd wedi newid. Gyda llaw, dyma un o'r rhesymau sy'n atal storio llawer o ficrowasanaethau o un cais mewn un ystorfa Git.
Hefyd, mae tagio sy'n seiliedig ar gynnwys yn ddull tagio mwy dibynadwy na thagio ar ganghennau Git, oherwydd nid yw cynnwys y delweddau canlyniadol yn dibynnu ar y drefn y caiff piblinellau eu gweithredu yn y system CI ar gyfer cydosod ymrwymiadau lluosog o'r un gangen.
Mae'n bwysig: gan ddechreu o hyn llofnod cam - A yw yr unig strategaeth dagio a argymhellir. Fe'i defnyddir yn ddiofyn yn y gorchymyn werf ci-env (oni bai eich bod yn nodi cynllun tagio gwahanol yn benodol).
. Bydd cyhoeddiad ar wahân hefyd yn cael ei neilltuo i'r nodwedd hon. DIWEDDARWYD (Ebrill 3): Erthygl gyda manylion .
Lefelau logio
Bellach mae gan y defnyddiwr gyfle i reoli'r allbwn, gosod y lefel logio a gweithio gyda gwybodaeth dadfygio. Opsiynau wedi'u hychwanegu --log-quiet, --log-verbose, --log-debug.
Yn ddiofyn, mae'r allbwn yn cynnwys y wybodaeth leiaf:
Wrth ddefnyddio allbwn berfol (--log-verbose) gallwch weld sut mae werff yn gweithio:
Allbwn manwl (--log-debug), yn ogystal â gwybodaeth dadfygio werff, hefyd yn cynnwys logiau o lyfrgelloedd a ddefnyddir. Er enghraifft, gallwch weld sut mae rhyngweithio â Chofrestrfa'r Docwyr yn digwydd, a hefyd cofnodi'r mannau lle treulir llawer iawn o amser:
Cynlluniau ar gyfer y dyfodol
Sylw! Mae'r opsiynau a ddisgrifir isod wedi'u marcio v1.1 yn dod ar gael yn y fersiwn hwn, llawer ohonynt yn y dyfodol agos. Daw diweddariadau trwy ddiweddariadau awtomatig . Nid yw'r nodweddion hyn yn effeithio ar ran sefydlog swyddogaethau v1.1; ni fydd angen ymyrraeth defnyddiwr â llaw mewn ffurfweddiadau presennol i'w hymddangosiad.
Cefnogaeth lawn i amrywiol weithrediadau Cofrestrfa Docker (NEWYDD)
- Fersiwn: v1.1
- Dyddiadau: Mawrth
Y nod yw i'r defnyddiwr ddefnyddio gweithrediad arferol heb gyfyngiadau wrth ddefnyddio werff.
Ar hyn o bryd, rydym wedi nodi’r set ganlynol o atebion yr ydym yn mynd i warantu cefnogaeth lawn ar eu cyfer:
- Diofyn (llyfrgell/cofrestrfa)*,
- AWS ECR
- Aswr*,
- Canolbwynt y Dociwr
- GCR*,
- Pecynnau GitHub
- Cofrestrfa GitLab*,
- Harbwr*,
- Cei.
Mae atebion sy'n cael eu cefnogi'n llawn ar hyn o bryd gan werff wedi'u nodi â seren. I eraill mae cefnogaeth, ond gyda chyfyngiadau.
Gellir nodi dwy brif broblem:
- Nid yw rhai atebion yn cefnogi tynnu tagiau gan ddefnyddio API Cofrestrfa Docker, gan atal defnyddwyr rhag defnyddio glanhau awtomatig werf. Mae hyn yn wir am AWS ECR, Docker Hub, a Phecynnau GitHub.
- Nid yw rhai atebion yn cefnogi ystorfeydd nythu fel y'u gelwir (Docker Hub, Pecynnau GitHub a Quay) nac yn eu gwneud, ond rhaid i'r defnyddiwr eu creu â llaw gan ddefnyddio'r UI neu'r API (AWS ECR).
Rydyn ni'n mynd i ddatrys y problemau hyn a phroblemau eraill gan ddefnyddio APIs brodorol yr atebion. Mae'r dasg hon hefyd yn cynnwys cwmpasu'r cylchred llawn o weithrediad werff gyda phrofion ar gyfer pob un ohonynt.
Adeiladu delwedd wedi'i ddosbarthu (↑)
- Fersiwn: v1.2 v1.1 (mae'r flaenoriaeth ar gyfer gweithredu'r nodwedd hon wedi'i chynyddu)
- Dyddiadau: Mawrth-Ebrill Mawrth
Ar hyn o bryd, dim ond ar un gwesteiwr pwrpasol y gellir defnyddio werf v1.0 a v1.1 ar gyfer gweithrediadau adeiladu a chyhoeddi delweddau a defnyddio'r cymhwysiad i Kubernetes.
Er mwyn agor posibiliadau gwaith gwasgaredig werff, pan fydd adeiladu a defnyddio cymwysiadau yn Kubernetes yn cael eu lansio ar sawl gwesteiwr mympwyol ac nad yw'r gwesteiwyr hyn yn arbed eu cyflwr rhwng adeiladau (rhedwyr dros dro), mae angen werf i weithredu'r gallu i ddefnyddio Cofrestrfa'r Docker fel storfa lwyfan.
Yn flaenorol, pan oedd y prosiect werf yn dal i gael ei alw'n dapp, roedd ganddo gyfle o'r fath. Fodd bynnag, rydym wedi dod ar draws nifer o faterion y mae angen eu hystyried wrth weithredu'r swyddogaeth hon yn werff.
Nodyn. Nid yw'r nodwedd hon yn ei gwneud yn ofynnol i'r casglwr weithio y tu mewn i godau Kubernetes, oherwydd I wneud hyn, mae angen i chi gael gwared ar y ddibyniaeth ar y gweinydd Docker lleol (yn y pod Kubernetes nid oes mynediad i'r gweinydd Docker lleol, oherwydd mae'r broses ei hun yn rhedeg mewn cynhwysydd, ac nid yw ac ni fydd werf yn cefnogi gweithio gyda'r gweinydd Docker dros y rhwydwaith). Bydd cefnogaeth ar gyfer rhedeg Kubernetes yn cael ei gweithredu ar wahân.
Cefnogaeth swyddogol i GitHub Actions (NEWYDD)
- Fersiwn: v1.1
- Dyddiadau: Mawrth
Yn cynnwys dogfennaeth werf (adrannau cyfeirio и arwain), yn ogystal â'r GitHub Action swyddogol ar gyfer gweithio gyda werf.
Yn ogystal, bydd yn caniatáu i werff weithio ar redwyr byrhoedlog.
Bydd mecanwaith rhyngweithio defnyddwyr â'r system CI yn seiliedig ar osod labeli ar geisiadau tynnu i gychwyn rhai camau gweithredu i adeiladu / cyflwyno'r rhaglen.
Datblygu lleol a defnyddio ceisiadau gyda weff (↓)
- Fersiwn: v1.1
- Dyddiadau: Ionawr-Chwefror Ebrill
Y prif nod yw cyflawni un ffurfwedd unedig ar gyfer defnyddio cymwysiadau yn lleol ac wrth gynhyrchu, heb gamau gweithredu cymhleth, allan o'r bocs.
Mae hefyd yn ofynnol i werf fod â modd gweithredu lle bydd yn gyfleus i olygu cod y cais a derbyn adborth ar unwaith o'r cymhwysiad sy'n rhedeg ar gyfer dadfygio.
Algorithm glanhau newydd (NEWYDD)
- Fersiwn: v1.1
- Dyddiadau: Ebrill
Yn y fersiwn gyfredol o werf v1.1 yn y weithdrefn cleanup Nid oes darpariaeth ar gyfer glanhau delweddau ar gyfer y cynllun tagio seiliedig ar gynnwys - bydd y delweddau hyn yn cronni.
Hefyd, mae'r fersiwn gyfredol o werf (v1.0 a v1.1) yn defnyddio gwahanol bolisïau glanhau ar gyfer delweddau a gyhoeddir o dan gynlluniau tagio: cangen Git, Git tag neu Git commit.
Dyfeisiwyd algorithm newydd ar gyfer glanhau delweddau yn seiliedig ar hanes ymrwymiadau yn Git, unedig ar gyfer pob cynllun tagio:
- Peidiwch â chadw mwy na delweddau N1 sy'n gysylltiedig â'r ymrwymiadau diweddaraf N2 ar gyfer pob git HEAD (canghennau a thagiau).
- Storiwch ddim mwy na delweddau cam N1 sy'n gysylltiedig â'r ymrwymiadau diweddaraf N2 ar gyfer pob git HEAD (canghennau a thagiau).
- Storio'r holl ddelweddau a ddefnyddir mewn unrhyw adnoddau clwstwr Kubernetes (mae holl gyd-destunau kube y ffeil ffurfweddu a'r gofodau enw yn cael eu sganio; gallwch gyfyngu ar yr ymddygiad hwn gydag opsiynau arbennig).
- Storio'r holl ddelweddau a ddefnyddir mewn maniffestau cyfluniad adnoddau sydd wedi'u cadw mewn datganiadau Helm.
- Gellir dileu delwedd os nad yw'n gysylltiedig ag unrhyw HEAD o git (er enghraifft, oherwydd bod y HEAD cyfatebol ei hun wedi'i ddileu) ac nid yw'n cael ei ddefnyddio mewn unrhyw faniffestau yng nghlwstwr Kubernetes ac mewn datganiadau Helm.
Adeiladu delwedd gyfochrog (↓)
- Fersiwn: v1.1
- Dyddiadau: Ionawr-Chwefror Ebrill*
Mae'r fersiwn gyfredol o werff yn casglu'r delweddau a'r arteffactau a ddisgrifir yn werf.yaml, yn ddilyniannol. Mae angen cyfochrog â'r broses o gydosod camau annibynnol o ddelweddau ac arteffactau, yn ogystal â darparu allbwn cyfleus ac addysgiadol.
* Sylwch: mae'r dyddiad cau wedi'i symud oherwydd mwy o flaenoriaeth ar gyfer gweithredu cynulliad dosbarthedig, a fydd yn ychwanegu mwy o alluoedd graddio llorweddol, yn ogystal â'r defnydd o werff gyda GitHub Actions. Cydosod cyfochrog yw'r cam optimeiddio nesaf, gan ddarparu scalability fertigol wrth gydosod un prosiect.
Pontio i Helm 3 (↓)
- Fersiwn: v1.2
- Dyddiadau: Chwefror-Mawrth Mai*
Yn cynnwys mudo i godbase newydd a ffordd brofedig, gyfleus i fudo gosodiadau presennol.
* Sylwch: ni fydd newid i Helm 3 yn ychwanegu nodweddion arwyddocaol i werff, oherwydd mae holl nodweddion allweddol Helm 3 (3-way-merge a dim tiller) eisoes wedi'u gweithredu yn werff. Ar ben hynny, werff wedi yn ychwanegol at y rhai a nodir. Fodd bynnag, mae'r trawsnewid hwn yn parhau yn ein cynlluniau a bydd yn cael ei roi ar waith.
Jsonnet am ddisgrifio cyfluniad Kubernetes (↓)
- Fersiwn: v1.2
- Dyddiadau: Ionawr-Chwefror Ebrill-Mai
Bydd Werf yn cefnogi disgrifiadau cyfluniad ar gyfer Kubernetes mewn fformat Jsonnet. Ar yr un pryd, bydd werff yn parhau i fod yn gydnaws â Helm a bydd dewis o fformat disgrifio.
Y rheswm yw bod gan dempledi Go, yn ôl llawer o bobl, rwystr mynediad uchel, ac mae dealladwy cod y templedi hyn hefyd yn dioddef.
Mae'r posibilrwydd o gyflwyno systemau disgrifio cyfluniad Kubernetes eraill (er enghraifft, Kustomize) hefyd yn cael ei ystyried.
Yn gweithio y tu mewn i Kubernetes (↓)
- Fersiwn: v1.2
- Dyddiadau: Ebrill-Mai Mai-Mehefin
Nod: Sicrhewch fod delweddau'n cael eu hadeiladu a bod y rhaglen yn cael ei chyflwyno gan ddefnyddio rhedwyr yn Kubernetes. Y rhai. Gellir adeiladu, cyhoeddi, glanhau a defnyddio delweddau newydd yn uniongyrchol o godennau Kubernetes.
Er mwyn gweithredu'r gallu hwn, yn gyntaf mae angen i chi allu adeiladu delweddau gwasgaredig (gweler y pwynt uchod).
Mae hefyd angen cefnogaeth ar gyfer modd gweithredu'r adeiladwr heb weinydd Docker (h.y. adeiladu neu adeiladu gofod defnyddiwr tebyg i Kaniko).
Bydd Werf yn cefnogi adeiladu ar Kubernetes nid yn unig gyda Dockerfile, ond hefyd gyda'i adeiladwr Stapel gydag ailadeiladu cynyddrannol ac Ansible.
Cam tuag at ddatblygiad agored
Rydyn ni'n caru ein cymuned (, ) ac rydym am i fwy a mwy o bobl helpu i wneud wefr yn well, deall y cyfeiriad yr ydym yn symud ynddo, a chymryd rhan yn y datblygiad.
Yn bur ddiweddar penderfynwyd newid i er mwyn datgelu proses waith ein tîm. Nawr gallwch weld y cynlluniau uniongyrchol, yn ogystal â gwaith cyfredol yn y meysydd canlynol:
- ;
- ;
- ;
- .
Mae llawer o waith wedi’i wneud gyda materion:
- Wedi tynnu rhai amherthnasol.
- Mae'r rhai presennol yn cael eu dwyn i un fformat, gyda nifer digonol o fanylion a manylion.
- Ychwanegwyd materion newydd gyda syniadau ac awgrymiadau.
Sut i alluogi fersiwn v1.1
Mae'r fersiwn ar gael ar hyn o bryd yn (mewn sianeli sefydlog и craig-solet bydd datganiadau yn ymddangos wrth i sefydlogi ddigwydd, fodd bynnag ea ei hun eisoes yn ddigon sefydlog ar gyfer defnydd, oherwydd aeth drwy'r sianeli alffa и beta). Wedi'i actifadu yn y modd canlynol:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Casgliad
Mae'r bensaernïaeth storio llwyfan newydd ac optimeiddio adeiladwyr ar gyfer adeiladwyr Stapel a Dockerfile yn agor y posibilrwydd o weithredu adeiladau gwasgaredig a chyfochrog mewn werff. Cyn bo hir bydd y nodweddion hyn yn ymddangos yn yr un datganiad v1.1 a byddant ar gael yn awtomatig trwy'r mecanwaith diweddaru awtomatig (ar gyfer defnyddwyr ).
Yn y datganiad hwn, mae strategaeth dagio yn seiliedig ar gynnwys delwedd wedi'i hychwanegu - tagio sy'n seiliedig ar gynnwys, sydd wedi dod yn strategaeth ddiofyn. Mae'r prif log gorchymyn hefyd wedi'i ail-weithio: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Y cam arwyddocaol nesaf yw ychwanegu gwasanaethau dosbarthedig. Mae adeiladau gwasgaredig wedi dod yn flaenoriaeth uwch nag adeiladau cyfochrog ers v1.0 oherwydd eu bod yn ychwanegu mwy o werth at wefr: graddio adeiladwyr yn fertigol a chefnogaeth i adeiladwyr byrhoedlog mewn amrywiol systemau CI / CD, yn ogystal â'r gallu i wneud cefnogaeth swyddogol i GitHub Actions . Felly, symudwyd y terfynau amser gweithredu ar gyfer cynulliadau cyfochrog. Fodd bynnag, rydym yn gweithio i roi’r ddau bosibilrwydd ar waith cyn gynted â phosibl.
Dilynwch y newyddion! A pheidiwch ag anghofio ymweld â ni yn i greu problem, dod o hyd i un sy'n bodoli eisoes ac ychwanegu mantais, creu cysylltiadau cyhoeddus, neu wylio datblygiad y prosiect.
PS
Darllenwch hefyd ar ein blog:
- «»
- «";
- Cyfres o nodiadau am ddatblygiadau arloesol mewn werf:
- «";
- «";
- «";
- «'.
Ffynhonnell: hab.com