2015-08-04 25 views
7

Ho un problema piuttosto strano con TeamCity. Ho un'installazione di TeamCity, con agenti di build locali e remoti. Il server TeamCity è nascosto dietro IIS con ARR (Application Request Routing), per abilitare SSL, ecc. Ho la sensazione che questo potrebbe essere parte del problema, ma non ne sono sicuro. Un'altra ragione per sospettare che IIS sia parte del problema è che ho provato ad ospitare TeamCity su un'app Web di Azure e ho ottenuto esattamente lo stesso comportamento.problemi di pubblicazione artefatti al server TeamCity remoto su IIS

Il problema è che, dopo la costruzione, quando gli agenti di build tenta di pubblicare i manufatti al server, ho un 404 dal server TeamCity. TeamCity pensa che si tratti di un errore recuperabile (vedi registro), e continua a riprovare alcune volte. Alla fine, la pubblicazione fallisce.

Se devo configurare gli agenti locali per accedere TeamCity via http://localhost, tutto funziona liscio. Ma quando accedo tramite l'indirizzo pubblico (che è servito via IIS), ottengo 404. Il contenuto 404 si presenta come una pagina standard di IIS 404.

Ho tentato di impostare la verbosità di registrazione dell'agente su DEBUG, ma ancora non emette l'URL effettivo che sta tentando di chiamare.

Qualcuno ha qualche indizio su come risolvere questo? Ottenere l'agente di TeamCity per produrre l'URL per il quale ottiene il 404 sarebbe un buon inizio.

[Publishing artifacts] Publishing 1 file [F:/tc/ba3/temp/buildTmp/out/_PublishedWebSites/**/* => dist.zip] using [WebPublisher] 
[15:34:15][Publishing artifacts] Publishing 1 file [F:/tc/ba3/temp/buildTmp/out/_PublishedWebSites/**/* => dist.zip] using [ArtifactsCachePublisher] 
[15:35:10] 
[Publishing artifacts] Recoverable problem publishing artifacts (will retry): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">; 
<html xmlns="http://www.w3.org/1999/xhtml">; 
<head> 
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> 
<title>404 - File or directory not found.</title> 
<style type="text/css"> 
<!-- 
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} 
fieldset{padding:0 15px 10px 15px;} 
h1{font-size:2.4em;margin:0;color:#FFF;} 
h2{font-size:1.7em;margin:0;color:#CC0000;} 
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;} 
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF; 
background-color:#555555;} 
#content{margin:0 0 0 2%;position:relative;} 
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;} 
--> 
</style> 
</head> 
<body> 
<div id="header"><h1>Server Error</h1></div> 
<div id="content"> 
<div class="content-container"><fieldset> 
    <h2>404 - File or directory not found.</h2> 
    <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3> 
</fieldset></div> 
</div> 
</body> 
</html> 

risposta

10

EDIT: Ho trovato questo documentato sulle pagine TeamCity così:

https://confluence.jetbrains.com/display/TCD9/Known+Issues#KnownIssues-FailuretopublishartifactstoserverbehindIISreverseproxy

traccia richieste non riuscite (come detto Terri Rougeou Donahue) è stato lo strumento per aiutarmi. Ho avuto due errori.

1) In primo luogo, lo StaticFileHandler non è stato spento. Quindi, durante il tentativo di POST sull'URL /httpAuth/artefactUpload.html, StaticFileHandler ha provato a gestire la richiesta prima che ARR potesse gestirla.

2) Quando ho disattivato StaticFileHandler, è stato avviato il modulo RequestFiltering e ho restituito un codice di errore 404.13, che è "Lunghezza contenuto troppo grande". Dopo un po 'di ricerca su google, ho trovato questo, http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits, descrivendo il parametro maxAllowedContentLength, e ho detto "Il valore predefinito è 30000000, che è di circa 28,6 MB."

La soluzione era:

1) Spegnere StaticFileHandler per il sito web (mapping di gestore) 2) Modificare le proprietà di "Richiesta di filtraggio" impostazioni sul sito Web, impostare "lunghezza massima consentita di contenuti" per qualcosa di sensato. Ho aggiunto uno 0 (lo rende approssimativamente 286 MB, dato che gli artefatti possono diventare piuttosto grandi).

maxContentLength IIS settings window

+3

Abbiamo appena passato il server dietro il proxy ieri e stavo battendo la testa contro un muro cercando di capirlo. Grazie per l'aiuto!! – MattGWagner

+2

Fidati di me, c'è stato un sacco di headbanging (non del tipo buono) coinvolto anche nella mia parte, prima di capire finalmente la soluzione (con un eccellente aiuto da SO) –

+1

E ovviamente, ho trovato questa risposta circa 5 minuti dopo la pubblicazione un ticket di supporto con JetBrains ... problema risolto ora comunque. –

2

È possibile abilitare Failed Request Tracing sul server IIS che TeamCity sta schierando a. Ciò fornirebbe la posizione in cui si verifica 404.

+0

Grazie per il suggerimento. Tuttavia, non riesco a vedere la "Traccia richiesta non riuscita" in "Configurazione" in IIS, come indicato nell'articolo. –

+0

È inoltre necessario installare la funzionalità del server Web "Tracing": http://www.iis.net/configreference/system.webserver/tracing/tracefailedrequests –

+0

La traccia di richiesta non riuscita è un gioiello. C'erano due errori. Creo la mia risposta per elaborare. –