Questo è un po 'vecchio, ma lo risponderò comunque nel caso qualcuno si imbattesse in questa domanda.
In primo luogo, è utile per eseguire grugnito con i colori disabili, sia come console diagnostica ei registri di implementazione lottano con i codici ANSI. Per fare ciò, eseguire grunt --no-color. Questo dovrebbe riportare le informazioni STDOUT nella Console e nel log di distribuzione.
In secondo luogo, non è consigliabile utilizzare versioni verificate di Node o NPM. Windows Azure ha già queste build nell'ambiente e già è configurato per i percorsi temporanei speciali e i percorsi della cache necessari per eseguire entrambi al meglio.
Project Kudu è il motore di distribuzione che alimenta le distribuzioni di Azure, ma lo sapete già, poiché avete un file .deployment. Tuttavia, gli strumenti di riga di comando di Azure [npm install azure-cli --global] consentono di impacchettare alcuni script di distribuzione migliori che utilizzeranno l'installazione Node e NPM preinstallata di Azure.
azure site deploymentscript –-node
otterrà quello script di nodo di base.
Da lì, sono necessarie alcune modifiche a deploy.sh per ottenere l'esecuzione di Grunt, in modo affidabile. Entro deploy.sh è una sezione #Deployment. Sostituire il contenuto con il seguente:
# Deployment
# ----------
echo Handling node.js grunt deployment.
# 1. Select node version
selectNodeVersion
# 2. Install npm packages
if [ -e "$DEPLOYMENT_SOURCE/package.json" ]; then
eval $NPM_CMD install
exitWithMessageOnError "npm failed"
fi
# 3. Install bower packages
if [ -e "$DEPLOYMENT_SOURCE/bower.json" ]; then
eval $NPM_CMD install bower
exitWithMessageOnError "installing bower failed"
./node_modules/.bin/bower install
exitWithMessageOnError "bower failed"
fi
# 4. Run grunt
if [ -e "$DEPLOYMENT_SOURCE/Gruntfile.js" ]; then
eval $NPM_CMD install grunt-cli
exitWithMessageOnError "installing grunt failed"
./node_modules/.bin/grunt --no-color clean common dist
exitWithMessageOnError "grunt failed"
fi
# 5. KuduSync to Target
"$KUDU_SYNC_CMD" -v 500 -f "$DEPLOYMENT_SOURCE/dist" -t "$DEPLOYMENT_TARGET" -n "$NEXT_MANIFEST_PATH" -p "$PREVIOUS_MANIFEST_PATH" -i ".git;.hg;.deployment;deploy.sh"
exitWithMessageOnError "Kudu Sync to Target failed"
Questo farà eseguire npm install, seguito da bower install (se esiste bower.json), seguita da grunt clean common dist (se Gruntfile.js esiste), e, infine, un KuduSync nella vostra /wwwroot. (Nota: sostituisci "clean common dist" con qualsiasi attività Grunt che devi eseguire.)
Ci sono alcuni altri problemi a cui puoi partecipare. Scrivo questo in uno post on my personal blog, che include alcuni dei problemi che potresti incontrare.
Quando si dice "Remote Execution console", a cosa si riferisce? Prova ad avviare Diagnostic Console dalla root del servizio scm (stesso nome host di git url). Fallisce lì? Puoi incollare l'output esatto? Inoltre, se esiste un repository minimo che è possibile condividere, sarebbe utile indagare. È possibile che qualcosa venga bloccato dalla sandbox. –
@DavidEbbo Sì, mi riferisco alla console diagnostica. Non ci riesce. Ho appena ricevuto il C-prompt. Sto copiando dei file, cancellandone alcuni dopo averli copiati (non necessari, ma parte di un sottomodulo Git), eseguendo alcuni template e analizzando le variabili d'ambiente. Quindi roba piuttosto standard. Quale classificazione delle cose è bloccata dalla sandbox? –
Esattamente ciò che i blocchi sandbox possono essere sottili. Si consiglia inoltre di esaminare il dump diagnostico (https://github.com/projectkudu/kudu/wiki/Investigating-issues#getting-the-diagnostic-dump), che potrebbe contenere più informazioni. Se esiste un modo per condividere un repository minimo che ci consenta di vedere esattamente ciò che stai vedendo, dovremmo essere in grado di identificare cosa sta succedendo. –