Pagtatakda ng proxy para sa isang Jenkins Unix shell command

Para sa isang command sa isang Unix Jenkins agent, ilagay ang pagtatalaga ng proxy sa command na iyon:

node('linux') {
    sh 'http_proxy=http://build-proxy.example:8080 https_proxy=http://build-proxy.example:8080 ./build.sh'
}

Ipinapalagay ng halimbawa na may build script ang repository at binabasa ng mga tool ng agent ang mga pangalang ito ng environment. Pinapalitan ng mga pagtatalaga ang mga minanang halaga para sa command na iyon at sa mga anak nito. Hindi nila muling isinusulat ang palagiang environment ng makina. Para sa isang build step na kumukuha ng pampublikong artifact sa pinahihintulutang ruta nang walang proxy authentication, ang listahan ng HTTP proxy ay makapagbibigay ng mga kandidatong HTTP endpoint para sa mga halagang iyon.

Kung maraming Pipeline step ang dapat magbahagi ng override, gumamit ng withEnv block sa paligid ng mga step na iyon. Itinatala ng Jenkins na ang paghawak nito sa variable ay hindi sensitibo sa malaki o maliit na titik ngunit pinapanatili ang mga ito; suriin ang resultang baybay kapag ang isang Unix tool ay nangangailangan ng partikular na pangalang maliit ang titik.

Ang isang karaniwang export sa isang sh step ay pag-aari ng shell na iyon. Ang susunod na malayang shell step ay isang bagong proseso at hindi namamana ang mga pagbabago ng katabi nito.

Ilapat ang setting kung saan tumatakbo ang command. Ang mga download ng Jenkins controller at ang tool na inilunsad sa isang remote agent ay magkaibang gumagamit ng network. Ang matagumpay na pagsusuri ng update sa controller ay hindi nagpapatunay sa ruta ng command ng agent.