ഞങ്ങളുടെ മുൻ പോസ്റ്റിൽ, നേരിട്ടുള്ള വിഷബാധ എങ്ങനെ കണ്ടെത്താമെന്നും അതിൽ നിന്ന് സംരക്ഷിക്കാമെന്നും ഞങ്ങൾ കണ്ടു. Pipeline എക്സിക്യൂഷൻ (D-PPE). ആ ദുർബലത എങ്ങനെ കണ്ടെത്താമെന്നും ഞങ്ങൾ കണ്ടു, സൈജെനി സ്കാനർ, അതുപോലെ ചില സംരക്ഷണ സംവിധാനങ്ങളും.
വിഷം കൊടുത്തു Pipeline വധശിക്ഷ (PPE) ആക്രമണകാരിക്ക് പരിഷ്ക്കരിക്കാൻ കഴിയുമ്പോഴാണ് നിർമ്മിക്കുന്നത് pipeline രണ്ട് വഴികളിൽ ഏതെങ്കിലും:
- CI കോൺഫിഗറേഷൻ ഫയൽ പരിഷ്ക്കരിക്കുന്നതിലൂടെ (the pipeline) -> നേരിട്ടുള്ള പിപിഇ (ഡി-പിപിഇ)
- പരാമർശിച്ച ഫയലുകൾ പരിഷ്കരിക്കുന്നതിലൂടെ pipeline (ഉദാഹരണത്തിന്: ഉള്ളിൽ നിന്ന് പരാമർശിച്ച സ്ക്രിപ്റ്റുകൾ pipeline കോൺഫിഗറേഷൻ ഫയൽ) -> പരോക്ഷ PPE (I-PPE)
ഈ പോസ്റ്റിൽ, നമ്മൾ ഇൻഡയറക്ട് പിപിഇയിലേക്ക് ആഴത്തിൽ ഇറങ്ങും. പക്ഷേ, അതിനുമുമ്പ്, എന്റെ മുൻ പോസ്റ്റിന്റെ പൂരകമായി, ആദ്യം GitHub എങ്ങനെയാണ് എക്സ്ക്യൂഷൻ കൈകാര്യം ചെയ്യുന്നതെന്ന് നോക്കാം. pipelineഡി-പിപിഇക്കെതിരായ സംരക്ഷണ സംവിധാനങ്ങൾ എന്തൊക്കെയാണ് എന്നും.
എങ്ങനെയാണ് GitHub എക്സിക്യൂഷനെ സംരക്ഷിക്കുന്നത്? pipelineപിആർ-കളിൽ നിന്നാണോ വരുന്നത്?
പരിഷ്കരിച്ച ഫയലുകളുടെ നിർവ്വഹണവുമായി ബന്ധപ്പെട്ട് GitHub എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്? pipelines?
തിരുത്തപ്പെട്ടത് pipelineകൾ പുഷുകളിൽ നിന്നോ അല്ലെങ്കിൽ Pull Requests (പിആർ). ഒരു പ്രധാന മികച്ച രീതി എന്ന നിലയിൽ, ഒരു സംരക്ഷിത ശാഖയിലേക്ക് നേരിട്ടുള്ള "പുഷ്" ഒഴിവാക്കാനും ഉപയോഗിക്കാനും ശക്തമായി ശുപാർശ ചെയ്യുന്നു Pull Requests സംഭാവന ചെയ്ത ഏതെങ്കിലും കോഡ് സ്വീകരിക്കുന്നതിനുമുമ്പ് ചില അവലോകനങ്ങൾ നടപ്പിലാക്കുന്നതിനുള്ള ഒരു സംവിധാനമായി.
Pull Requests രണ്ട് വ്യത്യസ്ത ഉറവിടങ്ങളിൽ നിന്ന് വരാം:
- പിആർ-കൾ വരുന്നത് ഫോർക്ക്
- പിആർ-കൾ വരുന്നത് ശാഖകൾ
പിആർ-കൾ ഫോർക്ക് ഇതിൽ നിന്നെല്ലാം വരാം പൊതു or സ്വകാര്യ സംഭരണികൾ.
നമ്മൾ PPE (വിഷബാധയേറ്റത്) കൈകാര്യം ചെയ്യുന്നതിനാൽ Pipeline നിർവ്വഹണം), ഞങ്ങളുടെ പ്രധാന കാര്യം ഒരു PR ന്റെ "സ്വീകാര്യത"യല്ല, മറിച്ച് പരിഷ്കരിച്ച ഒരു pipeline പിആറിന്റെ സ്വീകാര്യത/അംഗീകാര പ്രക്രിയയിൽ. ഒരു പിപിഇ ആക്രമണത്തിന്റെ കാതലായ ഭാഗത്ത്, "ക്ഷുദ്രകരമായ" പരിഷ്കരിച്ച ഒരു ഉദ്ദേശിക്കാത്ത വധശിക്ഷ നടക്കുന്നു. pipeline.
ചുരുക്കം വാക്കുകളിൽ പറഞ്ഞാൽ, വിഷം കലർത്തി Pipeline എക്സിക്യൂഷൻ (PPE) നിർമ്മിക്കുന്നത് ആക്രമണകാരിക്ക് പരിഷ്കരിക്കാൻ കഴിയും pipeline തര്ക്കശാസ്തം.
രണ്ട് ഉണ്ട് വേരിയന്റുകൾ:
- നേരിട്ടുള്ള പിപിഇ (ഡി-പിപിഇ): ഒരു D-PPE സാഹചര്യത്തിൽ, ആക്രമണകാരി CI കോൺഫിഗറേഷൻ ഫയൽ പരിഷ്കരിക്കുന്നു. റിപ്പോയിലെ ഒരു സുരക്ഷിതമല്ലാത്ത റിമോട്ട് ബ്രാഞ്ചിലേക്ക് നേരിട്ട് മാറ്റം വരുത്തിക്കൊണ്ടോ അല്ലെങ്കിൽ ഒരു ബ്രാഞ്ചിൽ നിന്നോ ഫോർക്കിൽ നിന്നോ ഉള്ള മാറ്റം ഉപയോഗിച്ച് ഒരു PR സമർപ്പിച്ചുകൊണ്ടോ അവർക്ക് ആക്‌സസ് ഉള്ള ഒരു റിപ്പോസിറ്ററിയിൽ. സി.ഐ മുതൽ pipeline പരിഷ്കരിച്ച CI കോൺഫിഗറേഷൻ ഫയലിലെ കമാൻഡുകൾ അനുസരിച്ചാണ് എക്സിക്യൂഷൻ നിർവചിക്കുന്നത്, ബിൽഡ് കഴിഞ്ഞാൽ ആക്രമണകാരിയുടെ ക്ഷുദ്ര കമാൻഡുകൾ ഒടുവിൽ ബിൽഡ് നോഡിൽ പ്രവർത്തിക്കുന്നു. pipeline ട്രിഗർ ചെയ്‌തിരിക്കുന്നു.
- പരോക്ഷ PPE (ഐ-പിപിഇ): ചില സന്ദർഭങ്ങളിൽ, ഒരു എതിരാളിക്ക് D-PPE യുടെ സാധ്യത ലഭ്യമല്ല, അതിൽ SCM സംഭരണി (ഉദാ. എങ്കിൽ pipeline ഒരേ റിപ്പോസിറ്ററിയിലെ ഒരു പ്രത്യേക സംരക്ഷിത ശാഖയിൽ നിന്ന് CI കോൺഫിഗറേഷൻ ഫയൽ പിൻവലിക്കാൻ ക്രമീകരിച്ചിരിക്കുന്നു). അത്തരമൊരു സാഹചര്യത്തിൽ, വിഷം കലർത്തുന്നതിനുപകരം pipeline തന്നെ, ഒരു ആക്രമണകാരി പരാമർശിച്ച ഫയലുകളിലേക്ക് ക്ഷുദ്ര കോഡ് കുത്തിവയ്ക്കുന്നു pipeline (ഉദാഹരണത്തിന്: ഉള്ളിൽ നിന്ന് പരാമർശിച്ച സ്ക്രിപ്റ്റുകൾ pipeline കോൺഫിഗറേഷൻ ഫയൽ)
രണ്ട് സാഹചര്യങ്ങളിലും, പരിഷ്കരിച്ചത് GitHub നടപ്പിലാക്കും pipeline മുൻ അവലോകനത്തിന്റെയോ അംഗീകാരത്തിന്റെയോ ആവശ്യമില്ലാതെ.
ഫോർക്ക്സ് ഓൺ മുതൽ പിആർ-കൾ പൊതു ബാക്കി
പ്രോസസ്സ് ചെയ്യുമ്പോൾ സ്വഭാവം കോൺഫിഗർ ചെയ്യാൻ GitHub അനുവദിക്കുന്നു പൊതു സംഭരണികളിലെ ഫോർക്കുകളിൽ നിന്ന് വരുന്ന പിആർ-കൾ.
ഒരു ഫോർക്കിൽ നിന്ന് ഒരു PR വരുമ്പോൾ, അത് നടപ്പിലാക്കുന്നതിന് മുമ്പ് GitHub എല്ലായ്പ്പോഴും ഒരു നിശ്ചിത തലത്തിലുള്ള "അംഗീകാരം" നിർബന്ധിക്കുന്നു. pipeline പിആറുമായി ബന്ധപ്പെട്ടത്ഈ അംഗീകാര നിലവാരം ദുർബലമായ അംഗീകാരത്തിൽ നിന്ന് കർശനമായ അംഗീകാരത്തിലേക്ക് മാറുന്നു.
At ഓർഗനൈസേഷൻ ലെവൽ (Org>Settings>Actions>General), നിങ്ങൾക്ക് നിരവധി "അംഗീകാര" ഓപ്ഷനുകളിൽ നിന്ന് തീരുമാനിക്കാം:
ഏറ്റവും കർശനമായത് അവസാനത്തേതാണ് (“പുറത്തുള്ള എല്ലാ സഹകാരികളുടെയും അനുമതി ആവശ്യമാണ്”) കാരണം പുറത്തുനിന്നുള്ള സഹകാരികളിൽ നിന്നുള്ള ഫോർക്കുകളിൽ നിന്ന് PR വരുമ്പോൾ GitHub-ന് എല്ലായ്പ്പോഴും അംഗീകാരം ആവശ്യമാണ്.
എന്നാൽ ഈ കർശനമായ സാഹചര്യത്തിൽ പോലും, ഉണ്ട് വായിക്കാനും എഴുതാനും അനുമതിയുള്ള സഹകാരികൾ തമ്മിലുള്ള വ്യത്യാസങ്ങൾ.
- പിആർ വരുമ്പോൾ a വായിക്കുക ഉപയോക്താവ്, നടപ്പിലാക്കൽ pipeline നിർത്തിവച്ചിരിക്കുന്നു മാറ്റങ്ങൾക്ക് അംഗീകാരം ലഭിക്കുന്നതുവരെ. അംഗീകാരം ശരിയാണെങ്കിൽ, പരിഷ്കരിച്ചത് pipeline നടപ്പിലാക്കുന്നു.
- പിആർ വരുമ്പോൾ a എഴുതുക ഉപയോക്താവ്, അംഗീകാരം ആവശ്യമില്ല, പരിഷ്കരിച്ചത് pipeline എപ്പോഴും നടപ്പിലാക്കപ്പെടുന്നു !!
ഒരു ഉപസംഹാരമായി, പൊതു സംഭരണികളിലെ ഫോർക്കുകളിൽ നിന്ന് വരുന്ന പിആറുകൾ പിപിഇയിൽ നിന്ന് നേരിയ തോതിൽ സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു. ബാഹ്യ (വായിക്കുന്ന) ഉപയോക്താക്കളിൽ നിന്ന് ചില പരിരക്ഷകൾ ഉണ്ട്, എന്നാൽ ആന്തരിക (എഴുത്ത്) ഉപയോക്താക്കളുമായി ബന്ധപ്പെട്ട ഒന്നും തന്നെയില്ല.
ഏതാണ്ട് സ്വകാര്യ റിപ്പോകളിൽ നിന്നുള്ള ഫോർക്കുകളിൽ നിന്ന് വരുന്ന പിആർ-കൾ?
ഫോർക്ക്സ് ഓൺ മുതൽ പിആർ-കൾ സ്വകാര്യ ബാക്കി
ഈ സാഹചര്യത്തിൽ, GitHub ചില ഉപയോഗപ്രദമായ കോൺഫിഗറേഷൻ ക്രമീകരണങ്ങൾ നൽകുന്നു.
മുകളിലുള്ള ക്രമീകരണങ്ങൾ ഇവിടെ കോൺഫിഗർ ചെയ്യാം ശരീരാവയവം അല്ലെങ്കിൽ അത് റെപ്പോ നില.
എപ്പോൾ ഒരു ഓപ്ഷനും ചെക്ക് ചെയ്തിട്ടില്ല., GitHub ചെയ്യും അംഗീകാരം ചോദിക്കുക ഒപ്പം ഇത് പരിഷ്കരിച്ചത് നടപ്പിലാക്കില്ല pipeline. ഇതാണ് ഏറ്റവും സുരക്ഷിതമായ കോൺഫിഗറേഷൻ!!
ദി ഏറ്റവും സുരക്ഷിതമല്ലാത്ത കോൺഫിഗറേഷൻ എപ്പോൾ "ഫോർക്കിൽ നിന്ന് വർക്ക്ഫ്ലോകൾ പ്രവർത്തിപ്പിക്കുക pull request” പരിശോധിച്ചുഈ സാഹചര്യത്തിൽ, വായിക്കാനും എഴുതാനും ഉപയോഗിക്കുന്ന ഉപയോക്താക്കൾ രണ്ടുപേർക്കും ഒരുപോലെ, പരിഷ്കരിച്ചത് ഗിത്തബ് സ്വയമേവ നടപ്പിലാക്കും. pipeline!! ഈ സാഹചര്യം പോലും ആകാം മോശമായ " എങ്കിൽഫോർക്കിൽ നിന്ന് വർക്ക്ഫ്ലോകളിലേക്ക് റൈറ്റ് ടോക്കണുകൾ അയയ്ക്കുക pull requests" ഒപ്പം "ഫോർക്കിൽ നിന്ന് വർക്ക്ഫ്ലോകളിലേക്ക് രഹസ്യങ്ങളും വേരിയബിളുകളും അയയ്ക്കുക. pull requests” എന്നിവ പരിശോധിച്ചിരിക്കുന്നു. വ്യക്തമായി ന്യായീകരിക്കപ്പെടുന്നില്ലെങ്കിൽ ഇത് ചെയ്യരുത്!!
എങ്കിൽ “ഫോർക്കിന് അംഗീകാരം ആവശ്യമാണ് pull request വർക്ക്ഫ്ലോകൾ” പരിശോധിച്ചു, മുകളിലുള്ള സാഹചര്യം ഒരു പരിധിവരെ മെച്ചപ്പെടുത്തിയിരിക്കുന്നു: GitHub അംഗീകാരം ചോദിക്കും, പരിഷ്കരിച്ചത് നടപ്പിലാക്കില്ല. pipeline വായിക്കുന്ന ഉപയോക്താവിനായി, പക്ഷേ അത് ഇപ്പോഴും ഒരു എഴുത്ത് ഉപയോക്താവിനായി അത് നടപ്പിലാക്കും.
ഫോർക്കുകൾ കണ്ടു, എന്ത് പറ്റി? ശാഖകളിൽ നിന്ന് വരുന്ന പിആർ-കൾ?
പിആർ-കൾ ശാഖകൾ
ഈ സാഹചര്യം സംരക്ഷിക്കാൻ നിങ്ങൾ ആശ്രയിക്കണം ബ്രാഞ്ച് സംരക്ഷണ നിയമങ്ങൾ.
റിപ്പോ തലത്തിൽ, നിങ്ങൾക്ക് ഏത് ബ്രാഞ്ചിനും ബ്രാഞ്ച് പ്രൊട്ടക്ഷൻ നിയമങ്ങൾ സൃഷ്ടിക്കാൻ കഴിയും. ഈ നിയമങ്ങൾ ചിലത് ചേർക്കുന്നു സംരക്ഷിത ശാഖകളുടെ പരിഷ്കരണത്തിനുള്ള നിയന്ത്രണങ്ങൾ.
നിങ്ങൾ ഒരു നിയമം “” ആയി കോൺഫിഗർ ചെയ്‌താലുംഒരു ആവശ്യമാണ് pull request ലയിപ്പിക്കുന്നതിന് മുമ്പ്" ഒപ്പം "അംഗീകാരങ്ങൾ ആവശ്യമാണ്" പരിഷ്കരിച്ചത് pipeline പിആർ സൃഷ്ടിക്കുമ്പോൾ യാന്ത്രികമായി നടപ്പിലാക്കും..ലയന നടപടിക്ക് മാത്രമേ "അംഗീകാരം" ബാധകമാകൂ.
ഇൻഡയറക്ട് വിഷബാധയെക്കുറിച്ച് എന്താണ്? Pipeline വധശിക്ഷ
മുകളിൽ കണ്ടതുപോലെ, D-PPE-യെ ഇനിപ്പറയുന്ന രീതിയിൽ ലഘൂകരിക്കാം പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ്, എന്നാൽ അതു I-PPE-ക്ക് ബാധകമല്ല.
നിങ്ങൾ pull_request_target ഉപയോഗിക്കുകയാണെങ്കിൽ, ഡിഫോൾട്ട് ചെക്ക്ഔട്ട് അടിസ്ഥാന കോഡ് ആയിരിക്കും. എന്നാൽ സംഭാവന ചെയ്ത കോഡിലെ (PR കോഡ്) ചില പരിശോധനകൾ സാധൂകരിക്കണമെങ്കിൽ നിങ്ങൾ PR കോഡ് വ്യക്തമായി പരിശോധിക്കേണ്ടതുണ്ട്. അതിനാൽ, PR കോഡ് ഏതെങ്കിലും ഷെൽ സ്ക്രിപ്റ്റ് പരിഷ്കരിച്ചിട്ടുണ്ടെങ്കിൽ pipeline, "അടിസ്ഥാനം" (സുരക്ഷിതം) pipeline "പരിഷ്കരിച്ച" ഷെൽ സ്ക്രിപ്റ്റ് → പരോക്ഷ PPE!!
ഇതിനുള്ള പരിഹാരം കുറച്ചുകൂടി സങ്കീർണ്ണമാണ് (pull_request_target പോലുള്ള ഒരു മാന്ത്രിക ബുള്ളറ്റ് ഇല്ല).
നമ്മുടെ pipeline pull_request_target ഉപയോഗിക്കുന്നതിനാൽ ഇപ്പോൾ D-PPE-യിൽ സുരക്ഷിതമാണ്. പക്ഷേ അത് ഇപ്പോഴും I-PPE-ക്ക് ഇരയാകാൻ സാധ്യതയുണ്ട്.
നമ്മുടെ പരീക്ഷണ ഉദാഹരണത്തിൽ, ബിൽഡ് നിർമ്മിക്കുന്നതിന് അടിസ്ഥാനപരമായി പിആർ കോഡ് പരിശോധിക്കേണ്ടതുണ്ട്, പക്ഷേ ബിൽഡ് സൃഷ്ടിക്കുന്ന ആർട്ടിഫാക്റ്റിലാണ് പരിശോധനകൾ നടത്തുന്നത്.
അതുകൊണ്ട് .. രണ്ട് കോഡ്ബേസുകളും പരിശോധിക്കാത്തതെന്താണ്?
- പിആർ കോഡ് പരിശോധിക്കുക, കാരണം നമ്മൾ നിർമ്മിക്കാനും പരീക്ഷിക്കാനും ആഗ്രഹിക്കുന്നത് സംഭാവന ചെയ്ത കോഡാണ്.
- യഥാർത്ഥ പതിപ്പ് പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള അടിസ്ഥാന കോഡ് പരിശോധിക്കുക pipeline ബിൽഡ്/ടെസ്റ്റ് സ്ക്രിപ്റ്റുകളും
ഇത് ചെയ്യുന്നത് വ്യത്യസ്ത ഫോൾഡറുകളിലേക്കുള്ള ആ കോഡ്ബേസുകൾ പരിശോധിക്കുന്നു.: അടിസ്ഥാന കോഡ് റൂട്ട് ഫോൾഡറിലേക്കും PR മറ്റൊരു ഫോൾഡറിലേക്കും പരിശോധിക്കാവുന്നതാണ്. ഈ സാഹചര്യത്തിൽ, പുതിയ ഫോൾഡറിൽ സ്ഥാപിച്ചിരിക്കുന്ന കോഡിനെതിരെ റൂട്ട് ഫോൾഡറിൽ നിന്ന് ബിൽഡും ടെസ്റ്റ് സ്ക്രിപ്റ്റും ഞങ്ങൾ എക്സിക്യൂട്ട് ചെയ്യും.
തീർച്ചയായും ഇതൊരു എളുപ്പ പരിഹാരമാണ്!! പക്ഷേ, പഠന ആവശ്യങ്ങൾക്കായി വളരെ രസകരമായ ഒരു വകഭേദം ഞാൻ അവതരിപ്പിക്കാൻ ആഗ്രഹിക്കുന്നു (…)
സാമൂഹികം വർക്ക്ഫ്ലോ_റൺ ട്രിഗർ ഇവന്റ്
കൂടാതെ പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ്, GitHub മറ്റൊരു ട്രിഗർ ഇവന്റ് നൽകുന്നു: വർക്ക്ഫ്ലോ_റൺ. ഈ പരിപാടി അനുവദിക്കുന്നു ഒരു നിർവ്വഹണം pipeline മറ്റൊന്നിലേക്ക് വ്യവസ്ഥ ചെയ്തു pipelineനടപ്പിലാക്കൽ.
വർക്ക്ഫ്ലോ_റൺ ഒപ്പം പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ് ട്രിഗറുകൾ ഒരു കാര്യത്തിൽ സമാനമാണ്: രണ്ടും പ്രിവിലേജ്ഡ് മോഡിൽ എക്സിക്യൂട്ട് ചെയ്യപ്പെടും, കൂടാതെ, പിആർ പരിഷ്കാരങ്ങൾ ഉണ്ടെങ്കിലും, അടിസ്ഥാനം pipeline നടപ്പിലാക്കും !!
നമ്മുടെ ഇപ്പോഴത്തെ അവസ്ഥ നോക്കാം 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
[...]
ബിൽഡ് വിഭാഗം D-PPE-ക്ക് സുരക്ഷിതമാണ്, പക്ഷേ ടെസ്റ്റ് വിഭാഗം ഇപ്പോഴും I-PPE-ക്ക് ഇരയാകാൻ സാധ്യതയുണ്ട്.
ദി pipeline കാരണം D-PPE-ക്ക് അത് സുരക്ഷിതമാണ് പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ് ട്രിഗർ. എന്നാൽ ഒരു ബാഹ്യ ഷെൽ സ്ക്രിപ്റ്റ് ഉപയോഗിക്കുന്നതിനാൽ പരീക്ഷണ ഘട്ടം ഇപ്പോഴും I-PPE-ക്ക് ഇരയാകാൻ സാധ്യതയുണ്ട്.
I-PPE ഒഴിവാക്കൽ
മുകളിൽ പറഞ്ഞതിന്റെ ഉദ്ദേശ്യം pipeline സംഭാവന ചെയ്ത കോഡ് നിർമ്മിച്ച് പരിശോധിക്കുക, PPE-ക്ക് സുരക്ഷിതമായിരിക്കുക എന്നതാണ്.
അതുകൊണ്ട് .. എന്തുകൊണ്ട് വിഭജിക്കുന്നില്ല pipeline രണ്ടായി? ഒന്ന് നിർമ്മാണത്തിനും മറ്റൊന്ന് പരീക്ഷണത്തിനും..
- ആദ്യത്തേത് pipeline (ബിൽഡ് സിഐ) ചെയ്യും പിആർ കോഡ് പരിശോധിക്കുക (അത് നിർമ്മിക്കാൻ), നിർമ്മാണം നടത്തി ഒരു പുരാവസ്തു സൃഷ്ടിക്കുക.
- 2-ാമത് pipeline (ടെസ്റ്റ് സിഐ) ചെയ്യും ഷെൽ സ്ക്രിപ്റ്റ് മോഡിഫിക്കേഷൻ ഒഴിവാക്കാൻ ബേസ് കോഡ് പരിശോധിക്കുക. ആർട്ടിഫാക്റ്റിനെതിരെ യഥാർത്ഥ സ്ക്രിപ്റ്റുകൾ നടപ്പിലാക്കുക.
- ടെസ്റ്റ് CI സമന്വയിപ്പിക്കുന്നതിന് pipeline ബിൽഡ് CI-ക്ക് ശേഷം പ്രവർത്തിപ്പിക്കാൻ pipeline, നമ്മൾ ഉപയോഗിക്കും വർക്ക്ഫ്ലോ_റൺ ട്രിഗർ.
ഈ രീതിയിൽ:
- pipeline ബിൽഡ് സിഐ is സുരക്ഷിതമാണ് രണ്ടു പേർക്കും ഡി-പിപിഇ (കാരണം പുൾ_റിക്വസ്റ്റ്_ടാർഗെറ്റ്) ഒപ്പം ഐ-പിപിഇ (കാരണം അത് ഇനി ഷെൽ സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യുന്നില്ല).
- pipeline ടെസ്റ്റ് സിഐ കൂടിയാണ് സുരക്ഷിതമാണ് രണ്ടു പേർക്കും ഡി-പിപിഇ (കാരണം വർക്ക്ഫ്ലോ_റൺ) ഒപ്പം ഐ-പിപിഇ (കാരണം അത് യഥാർത്ഥ ഷെൽ സ്ക്രിപ്റ്റ് ലഭിക്കുന്നതിന് അടിസ്ഥാന കോഡ് പരിശോധിക്കുന്നു)
രണ്ടിന്റെയും കോഡ് നോക്കാം. pipelineഈ പരിഷ്കാരങ്ങൾ അനുസരിച്ച്...
1st pipeline (ബിൽഡ് സിഐ):
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 (ടെസ്റ്റ് സിഐ):
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
[...]
വൗ... നല്ല പരിഹാരം!! പക്ഷേ..... നമ്മൾ സുരക്ഷിതരാണോ? ഇല്ല എന്ന് എനിക്ക് പേടിയാണ് 😭
തീർച്ചയായും, ഞങ്ങൾ ഒരു പുതിയ ദുർബലത അവതരിപ്പിച്ചിരിക്കുന്നു!! ഏത്? ഇതായിരിക്കും ഞങ്ങളുടെ അടുത്ത പോസ്റ്റിന്റെ വിഷയം 🙂 … തുടരുക!!
PS: ക്ഷമിക്കണം, എനിക്ക് മിണ്ടാതിരിക്കാൻ കഴിയില്ല 🤐 ..നിങ്ങൾ കേട്ടിട്ടുണ്ടോ ആർട്ടിഫാക്റ്റ് വിഷബാധ ? 😂
