Vi sono sicuramente sulla strada giusta per quanto riguarda il file .xcscheme - - Ho riscontrato questo problema durante l'impostazione dei miei progetti!
Per i posteri, o almeno per chi arriva qui da una ricerca, qui ci sono due versioni di cose - la versione "Sono occupato, quindi solo i fatti per favore" e una discussione e una logica più coinvolgente. Entrambe queste versioni presuppongono che tu stia cercando di creare da un file Workspace; se non sei poi le mie scuse come questo principalmente applicabile ai progetti basati su uno spazio di lavoro.
abbreviato 'Fix-it' Versione
La causa principale è che il comportamento predefinito di schemi è quello di mantenere i regimi 'privato' fino a quando non sono specificamente indicati come condiviso. Nel caso di una build avviata dalla riga di comando, l'interfaccia utente di Xcode non viene mai eseguita e lo strumento xcoderun non ha una propria cache di Schemi con cui lavorare. L'obiettivo è generare, condividere e impegnare lo schema che si desidera eseguire:
- Su una copia di lavoro pulita del codice, aprire l'area di lavoro del progetto.
- Scegli Schema> Gestisci schemi ... dal menu del prodotto.
- Viene visualizzato l'elenco di schemi definiti per il progetto.
- Individuare lo schema Bamboo sta tentando di eseguire
- Assicurarsi che la casella 'Condivisa' sia selezionata per tale schema e che l'impostazione 'Contenitore' sia impostata su Workspace e non sul file di progetto stesso.
- Fare clic su "OK" per chiudere il foglio Gestisci schemi.
- Un nuovo file .xcscheme è stato creato nel progetto in WorkspaceName.xcworkspace/xcshareddata/xcschemes.
- Configura questo file nel repository ed esegui una build Bamboo.
Deeper Discussione e Razionale
Xcode 4 ha introdotto le aree di lavoro e schemi come un modo per contribuire a cercare di domare un po 'del caos che è inerente a trattare con la meccanica di progetti Xcode relativi cablaggi, costruire obiettivi e costruisci le configurazioni insieme. Lo spazio di lavoro stesso ha il proprio set di dati di configurazione che descrive ciascuna delle "caselle" più piccole di dati che contiene e funge da scheletro per il collegamento di file .xcodeproj e un insieme di dati di configurazione condivisi che vengono specchiati su ogni macchina dello sviluppatore o sistema CI .Questa è la potenza e la trappola degli spazi di lavoro - ci sono 1) molti modi in cui si possono ottenere le cose configurate correttamente al 100%, ma messe nel contenitore sbagliato o 2) inserite nel contenitore corretto, ma configurate in modo improprio rendendo così dati inaccessibili ad altre parti del sistema!
Il comportamento predefinito degli schemi Xcode 4 è generare automaticamente nuovi schemi man mano che i progetti vengono aggiunti al file di Workspace. Quelli tra voi che hanno aggiunto diversi file .xcodeproj potrebbero aver notato che l'elenco di schemi diventa rapidamente indisciplinato, specialmente quando i file di progetto vengono aggiunti, quindi rimossi e quindi letti nello stesso spazio di lavoro. Tutti gli schemi, creati automaticamente o creati manualmente, sono impostati come schemi "privati" visibili solo all'utente corrente anche quando i file .xcuserdata vengono impegnati con i dati e la configurazione del progetto. Questa è la causa principale di quell'errore di compilazione criptico Rapporti di bambù da xcodebuild: poiché Bamboo gestisce la compilazione tramite la riga di comando e non l'interfaccia utente Xcode, non ha l'opportunità per Schemi di generare automaticamente e fare affidamento solo su quelli che sono definiti nello spazio di lavoro stesso. Supponendo che avete configurato bambù per costruire da un'area di lavoro utilizzando un comando come questo:
xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyApplication -configuration Debug
xcodebuild va in cerca di file di < 'schema' Parametro Valore> .xcscheme esistente al < 'lavoro' Parametro Valore>/xcshareddata/xcschemes.
Ovviamente ci sono molti modi in cui è possibile configurare sia Bamboo che un'area di lavoro, quindi tieni presente che la tua configurazione univoca potrebbe non mappare al 100% a quanto presentato qui. Il takeaway della chiave:
- Alcune operazioni automatiche che l'interfaccia utente Xcode si occupa magicamente non sono disponibili tramite la CLI di Xcodebuild.
- È possibile allegare schema e costruire i dati di configurazione a molti posti nella 'gerarchia del contenitore' - assicurarsi che i dati finisce nel contenitore giusto (Area di lavoro, di progetto, e/o costruire Target)
- considerare dove nel gerarchia dei contenitori lo strumento xcodebuild potrebbe essere alla ricerca di dati di configurazione; un grande indicatore di dove inizierà a guardare è basato sull'uso di argomenti "-workspace" o "-project".
La casella "Condivisa" è già selezionata ... e ora?
Ho riscontrato questo stesso problema sulla mia istanza Bamboo; si è scoperto che lo schema che è stato commesso nel mio repository era obsoleto e l'ultima versione degli strumenti da riga di comando non lo stava gestendo con garbo. Dato che questo esisteva in precedenza, ho dato un'occhiata alle impostazioni per assicurarmi che non ci fosse nulla di particolarmente brillante nello schema, cancellato e ricreato lo schema, assicurandomi che l'ho contrassegnato come "Condiviso" e riavviando il nuovo file .xcscheme al repository.
Se tutto sembra in ordine e la ricostruzione non risolve il problema, ricontrolla l'impostazione del contenitore: è davvero facile ottenere lo schema collegato al contenitore sbagliato nella gerarchia!
appena notato che quando apro il progetto in Xcode è creare un file .xcscheme, ma nella cartella xcuserdata/username.xcuserdatad ... ma non ottengo perché lo schema ottiene 'generato' sotto la cartella degli utenti .. e come gestirò quello in bambù –