Code Velocity
Kūrėjo įrankiai

GitHub Actions: 2026 m. balandžio mėn. atnaujinimai padidina CI/CD lankstumą ir saugumą

·5 min skaitymo·GitHub·Originalus šaltinis
Dalintis
GitHub Actions logotipas, vaizduojantis saugų ir lankstų CI/CD srautą su debesies integracija.

„GitHub Actions“ pristato pagrindinius atnaujinimus, skirtus didesniam CI/CD lankstumui ir saugumui

San Franciskas, Kalifornija – 2026 m. balandžio 3 d. – „GitHub Actions“, kertinis akmuo nuolatinei integracijai ir nuolatiniam pristatymui (CI/CD) kūrėjų bendruomenėje, pristatė keletą svarbių atnaujinimų, skirtų padidinti darbo srautų lankstumą, sustiprinti saugumą ir užtikrinti didesnį atsparumą šiuolaikinėms kūrimo platformoms. Šie 2026 m. balandžio pradžios leidimai atliepia ilgalaikius vartotojų prašymus ir kritinius veiklos poreikius, suteikdami kūrėjams ir įmonėms daugiau kontrolės ir patikimumo automatizuotuose darbo srautuose.

Pagrindiniai atnaujinimai apima labai lauktą galimybę pakeisti paslaugų konteinerių įvesties taškus ir komandas, visuotinai prieinamą saugyklų pasirinktinių savybių palaikymą „OpenID Connect“ (OIDC) žetonuose ir viešą „Azure VNET“ gedimo perkėlimo peržiūrą, skirtą „GitHub“ valdomiems vykdymo įrenginiams. Kartu šios funkcijos rodo nuolatinį „GitHub“ įsipareigojimą tobulinti savo CI/CD platformą, kad atitiktų sudėtingus šiandienos programinės įrangos kūrimo kraštovaizdžio reikalavimus.

„GitHub Actions“ darbo srautų tobulinimas naudojant paslaugų konteinerių pakeitimus

Daugelį metų „GitHub Actions“ naudojantys kūrėjai išreiškė norą griežčiau kontroliuoti paslaugų konteinerius savo darbo srautuose. Anksčiau numatytojo paslaugų konteinerių įvesties taško ar komandos pakeitimas reikalavo sudėtingų sprendimų, dažnai apsunkindamas darbo srautų YAML failus ir trukdydamas efektyviems CI/CD procesams.

„GitHub“ tiesiogiai išsprendė šią problemą, pristatydama naujus entrypoint ir command raktus. Dabar vartotojai gali sklandžiai pakeisti numatytąsias vaizdo konfigūracijas tiesiai iš savo darbo srauto YAML, atspindėdami pažįstamą ir intuityvią „Docker Compose“ naudojamą sintaksę. Šis atnaujinimas žymiai supaprastina konteinerizuotų paslaugų, tokių kaip duomenų bazės, talpyklos ar pasirinktiniai įrankiai, valdymą darbo srauto vykdymo metu, suteikdamas neprilygstamą lankstumą. Kūrėjai dabar gali lengvai konfigūruoti savo paslaugų konteinerius, kad jie veiktų tiksliai taip, kaip reikia testavimo ar kūrimo aplinkoms, sumažinant šabloninį kodą ir pagerinant darbo srauto skaitomumą.

Saugumo stiprinimas: OIDC žetonai su saugyklų pasirinktinėmis savybėmis

Saugumas debesies aplinkose yra itin svarbus, ir „GitHub Actions“ toliau tobulina savo galimybes šioje srityje. Saugyklų pasirinktinių savybių palaikymas „GitHub Actions OpenID Connect“ (OIDC) žetonuose dabar yra visuotinai prieinamas, peržengiant ankstesnį viešosios peržiūros statusą. Šis kritinis patobulinimas leidžia organizacijoms įterpti pasirinktines, vartotojo apibrėžtas savybes iš savo saugyklų tiesiai į OIDC žetonus, išduotus „GitHub Actions“.

Šios pasirinktinės savybės tarnauja kaip vertingos pretenzijos OIDC žetone, leidžiančios kurti sudėtingesnes ir detalesnes pasitikėjimo politikas su įvairiais debesų tiekėjais. Pavyzdžiui, organizacija gali apibrėžti pasirinktinę savybę, tokią kaip environment_type (pvz., „production“, „staging“, „development“) arba team_ownership (pvz., „frontend“, „backend“, „security“) tiesiogiai saugykloje. Kai darbo srautas iš tos saugyklos prašo OIDC žetono, šios savybės įtraukiamos kaip pretenzijos, kurias vėliau gali įvertinti debesų tiekėjo tapatybės ir prieigos valdymo (IAM) sistema. Šis perėjimas prie kontekstą atitinkančio autentifikavimo stiprina bendrą debesies prijungtų CI/CD platformų saugumo padėtį.

Debesies prieigos supaprastinimas naudojant detalias OIDC pasitikėjimo politikas

Saugyklų pasirinktinių savybių integravimas į OIDC žetonus suteikia didelių privalumų valdant debesies išteklių prieigą. Tai leidžia organizacijoms nustatyti tikrai detalias pasitikėjimo politikas, peržengiant individualių saugyklų pavadinimų ar ID išvardijimo apribojimus debesų tiekėjų konfigūracijose. Ši galimybė keičia didelių įmonių su sudėtingais valdymo modeliais veikimo būdą.

Su šiuo atnaujinimu komandos dabar gali:

  • Apibrėžti pasitikėjimo politikas, pagrįstas kontekstu: Kurti taisykles, suteikiančias prieigą pagal pasirinktines savybių reikšmes, tokias kaip aplinkos tipas, komandos nuosavybė, duomenų jautrumas ar atitikties lygiai. Pavyzdžiui, tik darbo srautams iš saugyklų, pažymėtų compliance_tier: PCI-DSS, gali būti suteikta prieiga prie konkrečių itin saugių debesies išteklių.
  • Sumažinti operacines išlaidas: Drastiškai sumažinti rankinį darbą, susijusį su debesies vaidmenų konfigūracijų palaikymu kiekvienai saugyklai. Vietoj to, politikos gali būti apibrėžtos vieną kartą ir plačiai taikomos pagal saugyklos atributus, supaprastinant valdymą, kai saugyklų skaičius auga.
  • Suderinti su organizaciniu valdymu: Sklandžiai integruoti debesies prieigos kontrolę su esamais organizaciniais saugyklų valdymo modeliais. Tai užtikrina, kad saugumo politikos būtų nuoseklios įvairiose priemonėse ir procesuose, didinant atitiktį ir audito galimybes.

Naudodamos šią funkciją, organizacijos gali pasiekti tvirtesnį ir labiau keičiamo dydžio požiūrį į debesies saugumą savo „GitHub Actions“ darbo srautuose, palengvinant saugų agent-driven-development-in-copilot-applied-science ir kitus pažangius automatizavimo scenarijus. Norėdami gauti daugiau informacijos apie darbo srautų saugumą, apsvarstykite galimybę išnagrinėti tokius išteklius kaip how-to-scan-for-vulnerabilities-with-github-security-labs-open-source-ai-powered-framework.

CI/CD atsparumo užtikrinimas: „Azure Private Networking VNET“ gedimo perkėlimas

Pasaulyje, kuriame nuolatinis pristatymas yra svarbiausia, kritiškai svarbu užtikrinti nepertraukiamą CI/CD platformų veikimą. „GitHub Actions“ žengia svarbų žingsnį didindama šį patikimumą, pristatydama viešą „Azure“ privataus tinklo peržiūrą, palaikančią VNET gedimo perkėlimą „GitHub“ valdomiems vykdymo įrenginiams. Ši funkcija leidžia organizacijoms sukonfigūruoti antrinį „Azure“ potinklį, kuris gali būti kitoje srityje, kaip atsarginę kopiją.

Jei pirminis potinklis taptų nepasiekiamas – galbūt dėl regioninio sutrikimo ar tinklo problemos – darbo srautai gali sklandžiai toliau veikti nurodytame gedimo perkėlimo potinklyje. Gedimo perkėlimo procesas gali būti inicijuojamas rankiniu būdu per tinklo konfigūracijos UI arba REST API, suteikiant administratoriams tiesioginę kontrolę, arba automatiškai „GitHub“ nustačius regioninį sutrikimą.

Štai naujų funkcijų santrauka:

FunkcijaAprašymasPagrindinė nauda
Paslaugų konteinerio įvesties taško pakeitimaiApibrėžkite pasirinktinius įvesties taškus ir komandas „Docker“ paslaugų konteineriams tiesiai darbo srautuose.Didesnis lankstumas, mažiau apribojimų, pažįstama „Docker Compose“ sintaksė.
OIDC saugyklų pasirinktinės savybėsIntegruokite saugykloje apibrėžtas pasirinktines savybes kaip pretenzijas į OIDC žetonus.Detali prieigos kontrolė, sumažinta debesies vaidmenų priežiūra, atitinka organizacijos valdymą.
„Azure VNET“ gedimo perkėlimasSukonfigūruokite antrinį „Azure“ potinklį valdomiems vykdymo įrenginiams, užtikrinant tęstinumą sutrikimų metu.Padidintas CI/CD atsparumas, automatinis/rankinis gedimo perkėlimas, sumažintos prastovos kritiniams darbo srautams.

Proaktyvios priemonės: „Azure VNET“ gedimo perkėlimas nepertraukiamam veikimui

VNET gedimo perkėlimo galimybė keičia žaidimo taisykles įmonių ir organizacijų paskyroms, kurios labai priklauso nuo „Azure“ privataus tinklo, skirto jų „GitHub“ valdomiems vykdymo įrenginiams. Gedimo perkėlimo atveju administratoriai nelieka nežinioje; audito žurnalų įvykiai ir el. pašto pranešimai siunčiami įmonių ir organizacijų administratoriams, informuojant apie veiklos būsenos pasikeitimą. Šis skaidrumas yra labai svarbus reaguojant į incidentus ir suprantant veiklos padėtį.

Svarbu pažymėti, kad nors automatinis gedimo perkėlimas užtikrina tiesioginį tęstinumą, jei gedimo perkėlimas inicijuojamas rankiniu būdu, administratoriai išlieka atsakingi už persijungimą atgal į pirminį regioną, kai jis atsigauna ir tampa visiškai prieinamas. Šis dvigubas požiūris suteikia tiek automatizuotą atsparumą, tiek administracinę kontrolę, leidžiančią organizacijoms valdyti savo CI/CD infrastruktūrą su pasitikėjimu ir tikslumu. Ši funkcija pabrėžia „GitHub“ įsipareigojimą teikti tvirtą ir patikimą infrastruktūrą kritinėms kūrimo darbo apkrovoms.

„DevOps“ ateitis: lankstumas ir saugumas „GitHub Actions“

Šie naujausi „GitHub Actions“ atnaujinimai rodo aiškią strateginę kryptį: suteikti kūrėjams daugiau kontrolės, padidinti saugumą sudėtingais mechanizmais ir užtikrinti maksimalų CI/CD platformų prieinamumą. Nuo paslaugų konteinerių valdymo supaprastinimo iki pažangių OIDC pagrindu veikiančių prieigos valdymų ir atsparaus „Azure“ tinklo siūlymo – „GitHub“ nuolat tobulina savo platformą, kad atitiktų besikeičiančius šiuolaikinio programinės įrangos kūrimo poreikius. Kadangi inovacijų tempas spartėja, tokie įrankiai kaip „GitHub Actions“ yra nepakeičiami siekiant išlaikyti lanksčius, saugius ir efektyvius kūrimo darbo srautus.

Dažniausiai užduodami klausimai

What are the new entrypoint and command overrides for GitHub Actions service containers?
GitHub Actions now allows developers to directly override the default entrypoint and command for service containers within their workflow YAML files. This new functionality addresses previous limitations that often required complex workarounds, providing a more streamlined and flexible approach to managing containerized services. The syntax is designed to be intuitive and familiar, mirroring the conventions used in Docker Compose, thereby reducing the learning curve for developers already accustomed to Docker environments. This enhancement significantly improves how users interact with and customize their CI/CD pipelines when working with services like databases or caches.
How do OIDC custom properties enhance security and simplify cloud access in GitHub Actions?
The general availability of OIDC custom properties for GitHub Actions tokens is a major security upgrade. This feature allows organizations to embed repository-defined custom properties as claims directly within their OpenID Connect (OIDC) tokens. By doing so, they can establish highly granular trust policies with cloud providers based on specific attributes such as environment type, team ownership, or compliance tier, rather than relying on less specific repository names or IDs. This not only strengthens access control by enforcing stricter, context-aware permissions but also drastically simplifies the management overhead associated with configuring cloud roles on a per-repository basis, making cloud access more secure and efficient.
What is Azure VNET failover for GitHub Actions hosted runners, and how does it ensure CI/CD resilience?
Azure private networking for GitHub Actions hosted runners now includes VNET failover capabilities, currently in public preview. This feature allows enterprises and organizations to configure a secondary Azure subnet, potentially in a different geographical region, as a backup. In the event that the primary subnet becomes unavailable due to an outage or other issues, the system can automatically or manually switch to this secondary subnet. This critical functionality ensures continuous operation of CI/CD workflows, significantly reducing downtime and maintaining the reliability of development pipelines, especially for mission-critical applications that demand high availability.
Which GitHub Actions users will benefit most from the new Azure VNET failover capabilities?
The Azure VNET failover feature is specifically designed for enterprise and organization accounts that utilize Azure private networking with GitHub-hosted runners. It is particularly beneficial for organizations with stringent uptime requirements, those operating in multi-region deployments, or those handling critical workloads where any disruption to CI/CD pipelines can lead to significant business impact. Companies prioritizing high availability and disaster recovery strategies for their development infrastructure will find this feature invaluable for maintaining operational continuity and enhancing the overall resilience of their software delivery lifecycle, offering peace of mind during regional outages.
How do the new OIDC custom properties reduce operational overhead for cloud resource access management?
The introduction of OIDC custom properties significantly reduces operational overhead by moving away from individual repository enumeration for cloud access policies. Instead of manually configuring and maintaining cloud roles for every single repository, organizations can now define broader trust policies based on custom property values like 'production-environment' or 'finance-team-compliance'. This allows for policy enforcement across categories of repositories, dramatically cutting down the administrative burden. Changes to organizational structure or repository classifications can be managed centrally via custom properties, which automatically propagate to OIDC claims, simplifying compliance and access control management at scale.
Can you provide examples of how OIDC custom properties can be used to define granular trust policies?
Certainly. With OIDC custom properties, organizations can define incredibly specific trust policies. For example, a property called `environment` with values like `dev`, `staging`, and `production` can be used. A policy could then dictate that only OIDC tokens from repositories marked `environment: production` are allowed to deploy to a production Azure resource group. Similarly, a `compliance_tier` property could classify repositories as `PCI-DSS` or `HIPAA-compliant`, allowing only tokens from these repositories to access sensitive cloud storage. Another use case is `team_ownership`, where only tokens from `team_A` repositories can modify `team_A` specific cloud services, aligning access with internal organizational structures and responsibilities.
What kind of notifications can users expect during an Azure VNET failover event?
During an Azure VNET failover event, GitHub ensures that enterprise and organization administrators are kept informed through multiple channels. When a failover occurs, whether triggered manually or automatically by GitHub due to a regional outage, relevant audit log events are generated. In addition to audit logs, affected administrators will also receive email notifications. This multi-channel notification system is crucial for transparent communication, allowing administrators to quickly understand the status of their CI/CD infrastructure, monitor the failover process, and take any necessary follow-up actions, such as manually switching back to the primary region once it becomes available.

Būkite informuoti

Gaukite naujausias AI naujienas el. paštu.

Dalintis