La SonarQube-vendejo bezonas la prokuran itineron de la servilo

La kontroloj de la vendejo kaj de ĝisdatigoj foriras de SonarQube, do agordu la subtenatajn sonar.properties-enigojn de la instalado:

http.proxyHost=proxy.example
http.proxyPort=8080
https.proxyHost=proxy.example
https.proxyPort=8080

Kunfandu la valorojn kaj faru plenan restartigon de la ĉefa servo per ĝia subtenata vivciklo. La provizita ekzemplo avertas, ke api/system/restart ne reŝargas ĉi tiun dosieron.

Gastigantoj estas nudaj nomoj/adresoj kun apartaj pordoj. HTTPS-ecoj elektas HTTPS-celojn, ne postulon je alia protokolo de prokura aŭskultanto. Mankanta HTTPS-gastiganto/pordo transprenas la HTTP-valorojn en la dokumentita agordo; eksplicitaj enskriboj gravas kiam la itineroj diversas. HTTP-adreso el la listo de HTTP-prokuroj povas plenigi ĉi tiujn kampojn por permesitaj publikaj vendejaj elŝutoj nur kiam nek http.proxyUser nek http.proxyPassword estas agorditaj.

Kie necesas aŭtentigo, http.proxyUser/http.proxyPassword de la referenco kovras HTTP-, HTTPS- kaj SOCKS-prokurojn. Uzu la konton de la peranto anstataŭ la ensaluto de la SonarQube-administranto.

Post la restartigo konservu la efektive malsukcesan servilflankan URL-on kaj la eraron. Ĝisdatigaj informoj kaj elektitaj kromaĵaj artefaktoj povas uzi malsamajn gastigantojn. Tio, ke la retumilo de la administranto atingas alian retejon, ne pruvas, ke la prokuro permesas ĉi tiun elŝuton.