የComposer የቆዩ HTTP_PROXY_REQUEST_FULLURI እና ተዛማጅ የFULLURI መፍትሄዎች በሰነዱ በተገለጸው አፈጻጸም ውስጥ ከእንግዲህ አያስፈልጉም አይጠቀሙም። የተዘነጋ ባንዲራ የሚሠራውን ደንበኛ መንገድ ማስተካከል አይችልም።

በPOSIX shell ውስጥ ለትዕዛዝ መስመር Composer፣ ከዚያ shell Composerን ከመጥራቱ በፊት የሚደገፉትን የፕሮክሲ ተለዋዋጮች export ያድርጉ፦

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080

ትናንሽ ፊደል ያላቸው ስሞች ይመረጣሉ። ፕሮክሲው ራሱ ተራ HTTP ሲጠቀም ሁለቱም እሴቶች በhttp:// ሊጀምሩ ይችላሉ፤ የHTTPS መድረሻ ወደ ፕሮክሲ የHTTPS ግንኙነት አይጠይቅም። የምሳሌውን endpoint በተፈቀደው አገልግሎት ይተኩ። የህዝብ መካከለኛ በሚፈቀድበት የህዝብ ጥቅል ማውረድ ላይ ከየHTTP ፕሮክሲ ዝርዝር HTTP እጩ ይምረጡ።

IDE ወይም build agent እሴቶቹን በራሱ የሂደት አካባቢ ይፈልጋል። ቋሚ ቅንብርን በኋላ መቀየር አስቀድሞ የሚሠራውን ሂደት አያዘምንም።

Composer ከCLI ውጭ ሲሠራ

ከCLI ውጭ ባለው ሁኔታ ለHTTP ጥያቄዎች Composer http_proxy ወይም HTTP_PROXY አይጠቀምም። በምትኩ CGI_HTTP_PROXYን ያሳያል፤ ይህም የጥያቄ ራስጌዎች እንደ ታማኝ የፕሮክሲ ውቅር እንዳይታሰቡ ይከላከላል። የshell መፍትሄውን ወደ ድር መተግበሪያ አይቅዱ፤ ከማይታመን ጥያቄ የፕሮክሲ ቅንብር አይውሰዱ።

ያልተሳካውን ክዋኔ ያንብቡ

ያልተፈታ የፕሮክሲ ስም፣ የተከለከለ ግንኙነት፣ 407 ተግዳሮት እና የምስክር ወረቀት ውድቀት ወደ ተለያዩ ደረጃዎች ይጠቁማሉ። የቆዩ የIPv6 ወይም የምስክር ወረቀት ማረጋገጫ መፍትሄዎችን ከመተግበር ይልቅ የመጀመሪያውን ትርጉም ያለው ስህተት ይጠቀሙ።

የComposer HTTP ማውረድ ሠርቶ በGit ላይ የተመሠረተ ጥገኝነት ካልተሳካ፣ የተለየውን የGit ሂደት፣ መንገዱን እና መለያውን ይመርምሩ። ይህ ከተሳካው የComposer ማውረድ የተለየ ተጠቃሚ ነው።

ተዛማጅ ጽሑፎች