በቀደመው ጽሑፋችን ላይ፣ ቀጥተኛ መርዛማነትን እንዴት መለየት እና መከላከል እንደሚቻል አይተናል Pipeline አፈፃፀም (ዲ-ፒፒኢ)። እንዲሁም ያንን ተጋላጭነት እንዴት መለየት እንደሚቻል አይተናል የኤክሲጂኒ ስካነርእንዲሁም አንዳንድ የመከላከያ ዘዴዎች።
የተመረዘ Pipeline አፈፃፀም (PPE) የሚፈጠረው አጥቂው विषायን ማስተካከል ሲችል ነው። pipeline ሎጂክ በሁለት መንገዶች፦
- የCI ውቅር ፋይልን በማሻሻል (እ.ኤ.አ. pipeline) -> ቀጥተኛ የPPE (D-PPE)
- በተጠቀሰው ፋይል የተጠቀሱ ፋይሎችን በማሻሻል pipeline (ለምሳሌ፡ ከውስጥ የተጠቀሱ ስክሪፕቶች pipeline የማዋቀሪያ ፋይል) -> ቀጥተኛ ያልሆነ PPE (I-PPE)
በዚህ ጽሑፍ ውስጥ፣ በተዘዋዋሪ የPPE (ኢንቮሉሽን ፒፒኢ) ላይ በጥልቀት እንመረምራለን። ነገር ግን ከዚያ በፊት እና ከቀደመው ጽሑፌ ጋር እንደ ተጨማሪ፣ GitHub የአፈፃፀም ሂደቱን እንዴት እንደሚያስተዳድር እንመልከት pipelineዎች እና ከ D-PPE ጋር የሚደረጉ የመከላከያ ዘዴዎች ምንድናቸው?
GitHub የአጠቃቀም አፈጻጸምን እንዴት ይከላከላል? pipelineከPRዎች ነው የሚመጣው?
GitHub የተሻሻለውን የአፈጻጸም አፈፃፀም በተመለከተ እንዴት ይሰራል? pipelines?
የተቀየረበት pipelineዎች ከፑሽ ወይም ከ Pull Requests (PR)። እንደ ዋና ምርጥ ልምምድ፣ ወደተጠበቀ ቅርንጫፍ በቀጥታ “መግፋት” እና መጠቀምን ማስወገድ በጥብቅ ይመከራል። Pull Requests ማንኛውንም የተበረከተ ኮድ ከመቀበልዎ በፊት የተወሰነ ግምገማ ለማስፈጸም እንደ ዘዴ።
Pull Requests ከሁለት የተለያዩ ምንጮች ሊመጣ ይችላል፡-
- የሚመጡ የህዝብ ግንኙነት (PRs) ሹካዎች
- የሚመጡ የህዝብ ግንኙነት (PRs) ቅርንጫፎች
የህዝብ ግንኙነት (PRs) ከ ሹካዎች ከሁለቱም ሊመጣ ይችላል ሕዝባዊ or የግል ማከማቻዎች
ከPP ጋር በምንገናኝበት ጊዜ (የተመረዘ) Pipeline አፈፃፀም)፣ ዋናው ነጥባችን የህዝብ ግንኙነት ግንኙነት “መቀበል” ሳይሆን የተሻሻለው አፈጻጸም ነው። pipeline የህዝብ ግንኙነት የህዝብ ግንኙነት ተቀባይነት/ማፅደቂያ ሂደት ወቅት። የPPE ጥቃት ዋና አካል፣ “ተንኮል አዘል” የተሻሻለ ያልተፈለገ አፈፃፀም አለ። pipeline.
በጥቂት ቃላት፣ ፖይደንድ Pipeline አፈፃፀም (PPE) የሚመረተው ሲሆነው አጥቂው ሊለውጠው ይችላል pipeline ሎጂክ.
ሁለት ናቸው ተለዋጮች:
- ቀጥተኛ የPPE (ዲ-ፒፒኢ): በD-PPE ሁኔታ፣ አጥቂው የCI ውቅር ፋይሉን ያስተካክላል በማከማቻ ውስጥ ለውጡን በቀጥታ ወደ ማከማቻው ላይ ወደተጠበቀ የርቀት ቅርንጫፍ በመጫን ወይም ከቅርንጫፍ ወይም ከሹካ የተገኘውን ለውጥ ከPR ጋር በማስገባት ማግኘት ይችላሉ። ከሲአይ ጀምሮ pipeline አፈፃፀም የሚገለጸው በተሻሻለው የCI ውቅር ፋይል ውስጥ ባሉት ትዕዛዞች ሲሆን፣ የአጥቂው ተንኮል አዘል ትዕዛዞች በመጨረሻ ግንባታው አንዴ ከተጠናቀቀ በኋላ በግንባታ ኖድ ውስጥ ይሰራሉ። pipeline ተቀጣጥሏል።
- ቀጥተኛ ያልሆነ የPPE (አይ-ፒፒኢ): በአንዳንድ ሁኔታዎች፣ የD-PPE እድል ለተቃዋሚው ተደራሽ አይደለም። SCM ማከማቻ (ለምሳሌ፡- pipeline የCI ውቅር ፋይልን ከተለየ፣ ከተጠበቀው ቅርንጫፍ በተመሳሳይ ማከማቻ ውስጥ ለማውጣት ተዋቅሯል)። በእንደዚህ አይነት ሁኔታ፣ ከመመረዝ ይልቅ pipeline በራሱ፣ አንድ አጥቂ በተጠቀሰው ፋይል ውስጥ ተንኮል አዘል ኮድ ያስገባል። pipeline (ለምሳሌ፡ ከውስጥ የተጠቀሱ ስክሪፕቶች pipeline የማዋቀሪያ ፋይል)
በሁለቱም በኩል ፣ GitHub የተሻሻለውን ያስፈጽማል pipeline ቀደም ሲል የተደረገ ግምገማ ወይም ማፅደቅ ሳያስፈልግ.
ከሹካዎች የተነሱ የህዝብ ግንኙነት መረጃዎች (PRs) በርቷል ሕዝባዊ መመለሻ
GitHub ሲሰራ ባህሪውን ማዋቀር ያስችላል በሕዝብ ማከማቻዎች ውስጥ ከሹካዎች የሚመጡ የህዝብ ግንኙነት ባለሙያዎች.
የህዝብ ግንኙነት ግንኙነት ከሹካ ሲመጣ፣ GitHub ሁልጊዜ የተወሰነ "እውቅና" ያስገድዳል። pipeline ከ PR ጋር የተያያዘይህ የማረጋገጫ ደረጃ ከደካማ ወደ ጥብቅ ማጽደቂያ ይቀየራል።
At የድርጅት ደረጃ (Org>>ቅንብሮች>>እርምጃዎች>>አጠቃላይ)፣ ከብዙ “ማጽደቂያ” አማራጮች መካከል መምረጥ ይችላሉ፡
በጣም ጥብቅ የሆነው የመጨረሻው ነው (“)ከሁሉም የውጭ ተባባሪዎች ይሁንታ ጠይቅ")" ምክንያቱም የህዝብ ግንኙነት ከውጭ ተባባሪዎች በሚመጣበት ጊዜ GitHub ሁልጊዜም ይሁንታ ይፈልጋል።
ግን በዚህ ጥብቅ ጉዳይ ላይ እንኳን፣ አሉ የማንበብ እና የመጻፍ ፈቃዶች ባላቸው ተባባሪዎች መካከል ያሉ ልዩነቶች.
- የህዝብ ግንኙነት (PR) ከ... ሲመጣ ያንብቡ ተጠቃሚ፣ የአፈፃፀም pipeline ቆሟል የለውጦች ማፅደቂያ እስኪገኝ ድረስ። ማፅደቁ ጥሩ ከሆነ የተሻሻለው ነገር አለ pipeline ተፈጽሟል።
- የህዝብ ግንኙነት (PR) ከ... ሲመጣ ጻፈ ተጠቃሚ፣ ማፅደቅ አያስፈልግም እና የተሻሻለው pipeline ሁልጊዜም ይፈጸማል!!
እንደ ማጠቃለያ፣ በሕዝብ ማከማቻዎች ላይ ከሚገኙ ሹካዎች የሚመጡ የህዝብ ግንኙነት አገልግሎቶች ከPPE በትንሹ የተጠበቁ ናቸው። ከውጭ (አንብብ) ተጠቃሚዎች የተወሰነ ጥበቃ አለ፣ ነገር ግን ከውስጣዊ (መጻፍ) ተጠቃሚዎች ጋር ምንም ግንኙነት የለውም።
ስለ ምን የግል ማከማቻዎች ከሚመጡ ሹካዎች የሚመጡ የህዝብ ግንኙነት አገልግሎቶች (PRs)?
ከሹካዎች የተነሱ የህዝብ ግንኙነት መረጃዎች (PRs) በርቷል የግል መመለሻ
በዚህ ሁኔታ፣ GitHub አንዳንድ ጠቃሚ የውቅር ቅንብሮችን ያቀርባል።
ከላይ ያሉት ቅንብሮች በ ላይ ሊዋቀሩ ይችላሉ ሕዋስ ወይም በ ሪፖ ደረጃ.
መቼ ምንም አማራጭ አልተረጋገጠም, GitHub ያደርጋል ይሁንታ ጠይቅ ና የተሻሻለውን ነገር ተግባራዊ አያደርግም pipelineይህ በጣም አስተማማኝ ውቅር ነው!!
የ በጣም ደህንነቱ ያልተጠበቀ ውቅር መቼ ነው "የስራ ፍሰቶችን ከፎርክ ያሂዱ pull request"ተፈትሿል"በዚህ ሁኔታ፣ ለሁለቱም ለማንበብም ሆነ ለመጻፍ ተጠቃሚዎች፣ Github የተሻሻለውን በራስ-ሰር ያስፈጽማል pipeline!! እናም ይህ ሁኔታ እኩል ሊሆን ይችላል የከፋ ከሆነ "ከፎርክ የጻፍ ቶከኖችን ወደ የስራ ፍሰቶች ይላኩ pull requests"እና"ሚስጥሮችን እና ተለዋዋጮችን ከፎርክ ወደ የስራ ፍሰቶች ይላኩ pull requests"ተፈትሸዋል። በግልጽ ካልተረጋገጠ በስተቀር ይህንን አታድርጉ!!
"ለሹካው ፈቃድ ጠይቅ pull request የስራ ፍሰቶች"" ከተረጋገጠ፣ ከላይ ያለው ሁኔታ በተወሰነ ደረጃ ተሻሽሏል፡ GitHub ማሻሻያውን እንዲያጸድቅ ይጠይቃል እና አይፈጽምም። pipeline ለንባብ ተጠቃሚ፣ ግን አሁንም ለጽሑፍ ተጠቃሚ ያስፈጽመዋል።
ሹካዎች ታይተዋል፣ ስለሱስ? ከቅርንጫፍ ቢሮዎች የሚመጡ የህዝብ ግንኙነት ባለሙያዎች (PRs)?
የህዝብ ግንኙነት (PRs) ከ ቅርንጫፎች
ይህንን ሁኔታ ለመጠበቅ የሚከተሉትን ማድረግ አለብዎት የቅርንጫፍ ጥበቃ ደንቦች.
በሪፖ ደረጃ፣ ለማንኛውም ቅርንጫፍ የቅርንጫፍ ጥበቃ ደንቦችን መፍጠር ይችላሉ። እነዚህ ደንቦች የተወሰኑትን ይጨምራሉ የተጠበቁ ቅርንጫፎችን ለማሻሻል ገደቦች.
ምንም እንኳን "ደንብ" ን ቢያዋቅሩምያስፈልጋል ሀ pull request ከመዋሃድ በፊት"እና"ማጽደቂያዎችን ጠይቅ" የተሻሻለው pipeline የህዝብ ግንኙነት ግንኙነት ሲፈጠር በራስ-ሰር ይፈጸማል"ማጽደቂያው" የሚተገበረው ለውህደት እርምጃው ብቻ ነው።
ኢንዳይሬክትድ ስለተባለው በሽታስ? Pipeline ማስፈጸም
ከላይ እንዳየነው፣ D-PPEን በመጠቀም መቀነስ ይቻላል pull_request_target, ግን እሱ ለ I-PPE አይተገበርም.
pull_request_target የሚጠቀሙ ከሆነ፣ ነባሪው የቼክ መውጫ መሰረታዊ ኮድ ይሆናል። ነገር ግን በተበረከተው ኮድ (PR ኮድ) ላይ አንዳንድ ቼኮችን ማረጋገጥ ከፈለጉ የPR ኮዱን በግልጽ ማረጋገጥ ያስፈልግዎታል። ስለዚህ፣ የPR ኮዱ በ... የተጠየቀውን ማንኛውንም የሼል ስክሪፕት ካሻሻለ pipeline, "መሰረታዊ" (ደህንነቱ የተጠበቀ) pipeline "የተሻሻለውን" የሼል ስክሪፕት → ቀጥተኛ ያልሆነ PPE እጠቀማለሁ!!
የዚህ መፍትሔ ትንሽ የበለጠ የተወሳሰበ ነው (እንደ pull_request_target ያለ አስማታዊ ጥይት የለም)።
የኛ pipeline አሁን ለD-PPE ደህንነቱ የተጠበቀ ነው ምክንያቱም pull_request_target እየተጠቀምን ነው። ነገር ግን አሁንም ለI-PPE ተጋላጭ ነው።
በሙከራ ምሳሌያችን ውስጥ፣ ግንባታውን ለመስራት የPR ኮዱን ማረጋገጥ አለብን፣ ነገር ግን ሙከራዎቹ የሚከናወኑት በግንባታው በተፈጠረው ቅርስ ላይ ነው።
ስለዚህ .. ሁለቱንም የኮድ ቤዞች ለምን አትፈትሹም?
- የህዝብ ግንኙነት ኮድን ይመልከቱ ምክንያቱም መገንባት እና መሞከር የምንፈልገው የተዋጣለት ኮድ ስለሆነ
- የመጀመሪያውን ስሪት ለማስኬድ የቼክአውት ቤዝ ኮድ pipeline እና የግንባታ/የሙከራ ስክሪፕቶች
ይህ ሊከናወን የሚችለው በ እነዚያን የኮድ ቤዞች ወደተለያዩ አቃፊዎች በመፈተሽ ላይየመሠረት ኮዱ ወደ ሩት ፎልደር ሊመረመር ይችላል፣ እና PR ደግሞ ወደ ሌላ ፎልደር ሊወጣ ይችላል። በዚህ ሁኔታ ግንባታውን እና የሙከራ ስክሪፕትን ከስር አቃፊው ወደ አዲሱ ፎልደር ከተቀመጠው ኮድ ጋር እናስኬዳለን።
ይህ በእርግጥ ቀላል መፍትሄ ነው!! ግን፣ ለትምህርት ዓላማ በጣም አስደሳች የሆነ አማራጭ ማስተዋወቅ እፈልጋለሁ (…)
የፊልሙ የስራ ፍሰት_ሩጫ የቀስቅሴ ክስተት
በተጨማሪ pull_request_target, GitHub ሌላ ቀስቅሴ ክስተት ያቀርባል፡ የስራ ፍሰት_ሩጫይህ ክስተት ይፈቅዳል የአፈፃፀም አንድ pipeline ለሌላ ሰው የተመደበ pipelineየአፈጻጸም.
የስራ ፍሰት_ሩጫ ና pull_request_target ቀስቅሴዎች በአንድ ገጽታ ተመሳሳይ ናቸው፡ ሁለቱም በልዩ ሁኔታ ይከናወናሉ እና፣ የህዝብ ግንኙነት (PR) ማሻሻያዎች ቢኖሩም፣ መሠረቱ pipeline ይፈጸማል!!
የአሁኑን ሁኔታችንን እንመልከት pipeline:
የግንባታ ክፍሉ ለዲ-ፒፒኢ ደህንነቱ የተጠበቀ ነው፣ ነገር ግን የሙከራ ክፍሉ አሁንም ለአይ-ፒፒኢ ተጋላጭ ነው።
የ pipeline ለዲ-ፒፒኢ ደህንነቱ የተጠበቀ ነው ምክንያቱም pull_request_target ቀስቅሴ። ነገር ግን የሙከራ ደረጃው ውጫዊ የሼል ስክሪፕት በመጥቀስ አሁንም ለI-PPE ተጋላጭ ነው።
የ I-PPE ማስወገድ
ከላይ የተጠቀሰው ዓላማ pipeline ለPPE ደህንነቱ የተጠበቀ እንዲሆን የተበረከተውን ኮድ መገንባት እና መሞከር ነው።
ስለዚህ .. ለምን አትከፋፍሉትም? pipeline ወደ ሁለት? አንዱ ለግንባታ ሌላኛው ደግሞ ለሙከራ..
- The 1st pipeline (ሲአይ ይገንቡ) ይሆናል የ PR ኮዱን ይመልከቱ (ለመገንባት)፣ ግንባታውን ሠሩ እና ቅርስ ፈጠሩ።
- 2nd pipeline (የሙከራ CI) ይሆናል የመሠረት ኮዱን ያረጋግጡ (የሼል ስክሪፕት ማሻሻያን ለማስቀረት) እና የመጀመሪያዎቹን ስክሪፕቶች ከቅርስ ጋር ያሂዱ።
- የሙከራ CIን ለማመሳሰል pipeline ከግንባታ CI በኋላ ለማስኬድ pipeline, እኛ እንጠቀማለን የስራ ፍሰት_ሩጫ ቀስቅሴ
በዚህ መንገድ፦
- pipeline ሲአይ ይገንቡ is አስተማማኝ ለሁለቱም ዲ-ፒፒኢ (በ ... ምክንያት pull_request_target) እና አይ-ፒፒኢ (ምክንያቱም የሼል ስክሪፕትን ከአሁን በኋላ አያስኬድም)።
- pipeline የሙከራ CI ደግሞ አስተማማኝ ለሁለቱም ዲ-ፒፒኢ (በ ... ምክንያት የስራ ፍሰት_ሩጫ) እና አይ-ፒፒኢ (ምክንያቱም የመጀመሪያውን የሼል ስክሪፕት ለማግኘት መሰረታዊ ኮዱን ስለሚፈትሽ)
የሁለቱንም ኮድ እንመልከት pipelineበእነዚህ ማሻሻያዎች መሠረት…
1st pipeline (CI ይገንቡ):
2nd pipeline (የሙከራ CI):
ዋው… ጥሩ መፍትሄ!! ግን ….. ደህና ነን? አይሆንም ብዬ እፈራለሁ 😭
በእርግጥም፣ አዲስ ተጋላጭነት አስተዋውቀናል!! የትኛው? ይህ የሚቀጥለው ጽሑፋችን ርዕሰ ጉዳይ ይሆናል 🙂 … ይከታተሉን!!
PS: ይቅርታ፣ ዝም ማለት አልችልም 🤐 ..ስለዚህ ነገር ሰምተሃል? የቅርስ መርዝ ? 😂
