Aurreko argitalpenean, Zuzeneko pozoitzea nola detektatu eta horren aurka babestu ikusi genuen Pipeline Exekuzioa (D-PPE). Ahultasun hori nola detektatu ere ikusi genuen erabiliz Xygeni eskanerra, baita babes-mekanismo batzuk ere.
Pozoituta Pipeline Exekuzioa (PPE) erasotzaileak alda dezakeenean sortzen da pipeline logika bi modu hauetako batean:
- CI konfigurazio fitxategia aldatuz (hau da, pipeline) -> Zuzeneko EPI (D-EPI)
- Erreferentziatutako fitxategiak aldatuz pipeline (adibidez: barruan erreferentziatutako scriptak pipeline konfigurazio fitxategia) -> Zeharkako EPI (I-EPI)
Mezu honetan, Zeharkako PPE-n sakonduko dugu. Baina, horren aurretik, eta aurreko mezuaren osagarri gisa, ikus dezagun nola kudeatzen duen GitHub-ek honen exekuzioa pipelineeta zeintzuk dira D-PPEren aurkako babes-mekanismoak?
Nola babesten du GitHub-ek exekuzioa pipelinePRetatik dator?
Nola funtzionatzen du GitHub-ek aldatutako exekuzioari dagokionez pipelines?
Modified pipelineBultzada edo Pull Requests (PR). Jardunbide egoki nagusi gisa, oso gomendagarria da babestutako adar batera zuzeneko "bultzada" saihestea eta erabiltzea Pull Requests edozein kode lagundu onartu aurretik berrikuspen batzuk ezartzeko mekanismo gisa.
Pull Requests bi iturri ezberdinetatik etor daiteke:
- PRak hemendik datozenak sardexkak
- PRak hemendik datozenak adarrak
PR-ak hemendik sardexkak etor daiteke bai publikoa or pribatua biltegiak.
EPIarekin (pozoitutakoekin) ari garenez Pipeline Exekuzioa), gure puntu nagusia ez da PR baten "onarpena", baizik eta aldaketa baten exekuzioa pipeline PRaren onarpen/baimen prozesuan zehar. EPI eraso baten muinean, "gaizto" den aldatutako sistema baten nahi gabeko exekuzioa dago. pipeline.
Hitz gutxitan, pozoituta Pipeline Exekuzioa (PPE) sortzen da noiz erasotzaileak alda dezake pipeline logika.
Badira bi aldaera:
- EPI zuzena (D-PPE): D-PPE eszenatoki batean, erasotzaileak CI konfigurazio fitxategia aldatzen du sarbidea duten biltegi batean, aldaketa zuzenean biltegiko urruneko adar babestu gabe batera bultzatuz, edo adar edo adar batetik aldaketarekin PR bat bidaliz. CItik aurrera pipeline exekuzioa aldatutako CI konfigurazio fitxategiko komandoek definitzen dute, erasotzailearen komando gaiztoak eraikuntza-nodoan exekutatzen dira eraikuntza amaitutakoan pipeline aktibatzen da.
- Zeharkako EPI (I-PPE): Zenbait kasutan, D-PPE aukera ez dago eskuragarri sarbidea duen aurkari batentzat SCM biltegia (adibidez, baldin eta pipeline CI konfigurazio fitxategia biltegi bereko adar babestu eta bereizi batetik ateratzeko konfiguratuta dago). Egoera horretan, pozoitu beharrean pipeline bera, erasotzaile batek kode gaiztoa txertatzen du erreferentziatutako fitxategietan pipeline (adibidez: barruan erreferentziatutako scriptak pipeline konfigurazio fitxategia)
Bi kasuetan, GitHub-ek aldatutakoa exekutatuko du pipeline aurretiko berrikuspen edo onespenik behar izan gabe.
Sardexkatik PRak publikoa gainerakoa
GitHub-ek prozesatzean portaera konfiguratzeko aukera ematen du PRak biltegi publikoetako adarretatik datozenak.
PR bat adar batetik datorrenean, GitHub-ek beti behartzen du "baimen" maila bat exekutatu aurretik. pipeline PR-rekin lotuta.Onarpen maila honek onarpen ahuletik zorrotzera aldatzen du.
At Erakunde maila (Erakundea>>Ezarpenak>>Ekintzak>>Orokorra), hainbat "baimen" aukera aukeratu ditzakezu:
Zorrotzena azkena da (“Kanpoko kolaboratzaile guztien onespena behar da”) GitHub-ek beti onarpena beharko duelako kanpoko kolaboratzaileen forketatik PRa datorrenean.
Baina kasu zorrotz honetan ere, badaude Irakurtzeko eta idazteko baimenak dituzten kolaboratzaileen arteko desberdintasunak.
- PRa batetik datorrenean irakurri erabiltzailea, -a fitxategiaren exekuzioa pipeline GELDITUTA dago aldaketak onartu arte. Onarpena ondo badago, aldatutakoa pipeline exekutatzen da.
- PRa batetik datorrenean idatzi erabiltzailea, -a ez da beharrezkoa baimenik eta aldatua pipeline beti exekutatzen da!!
Ondorio gisa, biltegi publikoetako forketatik datozen PRak babes gutxikoak dira PPEren aurka. Kanpoko (irakurtzeko) erabiltzaileen aurkako babes pixka bat badago, baina barneko (idazteko) erabiltzaileekin lotutako ezer ez.
Zer deritzozu PRak biltegi pribatuetatik datozen adarretatik datoz?
Sardexkatik PRak pribatua gainerakoa
Egoera honetan, GitHub-ek konfigurazio ezarpen erabilgarri batzuk eskaintzen ditu.
Goiko ezarpenak hemen konfigura daitezke: organoa edo, Biltegia maila.
Noiz ez dago aukerarik markatuta, GitHub-ek egingo du onarpena eskatu ez du aldatutakoa exekutatuko pipelineHau da konfiguraziorik seguruena!!
The konfigurazio arriskutsuena denean "Exekutatu lan-fluxuak bidegurutzetik pull request" markatuta dagoKasu honetan, irakurtzeko eta idazteko erabiltzaileentzat berdin, Github-ek automatikoki exekutatuko du aldatutakoa pipeline!! Eta egoera hau are gehiago izan daiteke okerragoa baldin eta “Bidali idazketa-tokenak lan-fluxuetara bidegurutzetik pull requests"Eta"Bidali sekretuak eta aldagaiak lan-fluxuetara bidegurutzetik pull requests" markatuta daude. Ez egin hau argi eta garbi justifikatuta ez badago!!
Bada “Sardexkarako baimena behar da pull request fluxuak" markatuta badago, goiko egoera hobetu egiten da zertxobait: GitHub-ek onarpena eskatuko du eta ez du aldatutakoa exekutatuko pipeline irakurtzeko erabiltzailearentzat, baina idazteko erabiltzailearentzat exekutatu egingo du oraindik.
Sardexkak ikusita, zer gertatzen da? Sukurtsaletatik datozen PRak?
PR-ak hemendik adarrak
Egoera hau babesteko, fidatu behar duzu Sukurtsalen Babeserako Arauak.
Biltegi mailan, edozein adarrentzako adar babesteko arauak sor ditzakezu. Arau hauek gehitzen dituzte... babestutako adarrak aldatzeko mugak.
Arau bat konfiguratzen baduzu ere “a exijitu pull request batu aurretik"Eta"Onarpenak behar dituzte" aldatua. pipeline PR sortzean automatikoki exekutatuko da«Onarpena» batuketa-ekintzari bakarrik aplikatuko zaio.
Zer gertatzen da zeharkako pozoitzearekin? Pipeline Execution
Goian ikusi dugun bezala, D-PPE arindu daiteke erabiliz eskaera_tiratzeko_helburua, baina ez da aplikatzen I-PPEri.
pull_request_target erabiltzen baduzu, lehenetsitako checkout-a oinarrizko kodea izango da. Baina lagundutako kodearen (PR kodearen) egiaztapen batzuk balioztatu nahi badituzu, PR kodea berariaz checkout egin behar duzu. Beraz, PR kodeak shell script-ak deitutako edozein aldatu badu... pipeline, “oinarria” (segurua) pipeline "aldatutako" shell script-a deituko du → Zeharkako PPE!!
Honen konponbidea zertxobait konplexuagoa da (ez dago pull_request_target bezalako bala magikorik).
Gure pipeline orain segurua da D-PPE-rako pull_request_target erabiltzen ari garelako. Baina oraindik zaurgarria da I-PPE-ren aurrean.
Gure proba-adibidean, PR kodea egiaztatu behar dugu funtsean eraikuntza egiteko, baina probak eraikuntzak sortutako artefaktuan exekutatzen dira.
Beraz .. Zergatik ez dituzu bi kode-baseak aztertzen?
- Checkout PR kodea, eraiki eta probatu nahi dugun kode partekatua baita.
- Jatorrizko bertsioa exekutatzeko oinarrizko kodea egiaztatu pipeline eta eraikitze/proba gidoiak
Hau egin daiteke honen bidez kode-base horiek karpeta desberdinetan egiaztatzeaoinarrizko kodea erroko karpetara atera daiteke, eta PR beste karpeta batera. Kasu honetan, eraikuntza eta proba-skripta erroko karpetatik exekutatuko genituzke karpeta berrian jarritako kodearen aurka.
Irtenbide erraza da hau, noski!! Baina, ikaskuntza helburuetarako, aldaera nahiko interesgarri bat aurkeztu nahi nuke (…)
GitHub lan-fluxuaren_exekuzioa gertaera eragilea
Gainera eskaera_tiratzeko_helburua, GitHub-ek beste abiarazle gertaera bat eskaintzen du: lan-fluxuaren_exekuzioaEkitaldi honek aukera ematen du baten exekuzioa pipeline beste batera baldintzatuta. pipelineren exekuzioa..
lan-fluxuaren_exekuzioa eskaera_tiratzeko_helburua abiarazleak antzekoak dira alderdi batean: biak modu pribilegiatuan exekutatuko dira eta, PR aldaketak gorabehera, oinarria pipeline exekutatuko dute!!
Ikus dezagun gure egungo pipeline:
name: PR TARGET CI
on:
pull_request_target:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
prt_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
with:
# This is to get the PR code instead of the repo code
ref: ${{ github.event.pull_request.head.sha }}
# Simulation of a compilation
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
ls -lR
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh
echo Tests executed.
#
# Let’s omit the check conditions at this moment …
#
- name: pr_check_conditions_to_merge
[...]
Eraikuntza atala D-PPErentzat segurua da, baina proba atala oraindik I-PPErentzat zaurgarria da.
The pipeline bera segurua da D-PPErako, horregatik eskaera_tiratzeko_helburua abiarazlea. Baina proba-urratsa oraindik I-PPEren aurrean zaurgarria da kanpoko shell script bat deitzeagatik.
I-PPE saihestea
Goikoen helburua. pipeline EPIrako segurua izanik, lagundutako kodea eraiki eta probatzea da.
Beraz .. Zergatik ez zatitu pipeline bitan? Bat eraikitzeko eta bestea probatzeko..
- 1st pipeline (CI eraikitzea) litzateke PR kodea begiratu (eraikitzeko), egin eraikuntza eta sortu artefaktu bat.
- 2.a pipeline (CI proba) litzateke Begiratu oinarrizko kodea (shell script-aren aldaketak saihesteko) eta exekutatu jatorrizko script-ak artefaktuaren aurka.
- Proba CI sinkronizatzeko pipeline CI eraikiaren ONDOREN exekutatzeko pipeline, erabiliko dugu lan-fluxuaren_exekuzioa abiarazlea.
Honela:
- pipeline CI eraikitzea is segurua biei D-PPE (ondorioz eskaera_tiratzeko_helburua) eta I-PPE (shell script-a jada ez duelako exekutatzen).
- pipeline CI proba da, halaber, segurua biei D-PPE (ondorioz lan-fluxuaren_exekuzioa) eta I-PPE (jatorrizko shell script-a lortzeko oinarrizko kodea egiaztatzen duelako)
Ikus dezagun bien kodea pipelinealdaketa hauen arabera…
1st pipeline (CI eraikia):
name: Build CI
on:
pull_request_target:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
GITHUB_PAT: ${{ secrets.GH_PAT }}
jobs:
prt_build_and_upload:
runs-on: ubuntu-latest
steps:
- name: Checking out PR code
uses: actions/checkout@v4
if: ${{ github.event_name == 'pull_request_target' }}
with:
# This is to get the PR code instead of the repo code
ref: ${{ github.event.pull_request.head.sha }}
- name: Building ...
run: |
mkdir ./bin
touch ./bin/mybin.exe
# Save some PR info for later use by the 2nd pipeline
echo "${{github.event.pull_request.title}}" > ./bin/PR_TITLE.txt
echo "${{github.event.number}}" > ./bin/PR_ID.txt
# Upload the binary as a pipeline artifact
- name: Archive building artifacts
uses: actions/upload-artifact@v3
with:
name: archive-bin
path: |
bin
2nd pipeline (CI proba):
ame: Test CI
on:
workflow_run:
workflows: [ 'PR TARGET CI' ]
types: [completed]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
GITHUB_PAT: ${{ secrets.GH_PAT }}
jobs:
deploy:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
# By default, checks out base code (not PR code)
- name: Checkout repository
uses: actions/checkout@v4
# Download the artifact
- name: 'Download artifact'
uses: actions/github-script@v6
with:
script: |
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
owner: context.repo.owner,
repo: context.repo.repo,
run_id: context.payload.workflow_run.id,
});
let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
return artifact.name == "archive-bin"
})[0];
let download = await github.rest.actions.downloadArtifact({
owner: context.repo.owner,
repo: context.repo.repo,
artifact_id: matchArtifact.id,
archive_format: 'zip',
});
let fs = require('fs');
fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/myartifact.zip`, Buffer.from(download.data));
# Unzip the artifact
- name: 'Unzip artifact'
run: |
unzip -o myartifact.zip
# Runs tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh
echo Tests executed.
#
# Let’s omit the check conditions at this moment …
#
- name: pr_check_conditions_to_merge
[...]
Aupa... irtenbide polita!! Baina... Seguru al gaude? Ez nago 😭
Bai, ahultasun berri bat aurkeztu dugu!! Zein? Hurrengo argitalpenaren gaia izango da hau 🙂 … Adi egon!!
PS: Barkatu, ezin naiz isilik egon 🤐 ..Entzun al duzu honen berri? Artefaktuen intoxikazioa ? 😂
