2013-01-16 9 views
109

Ho un problema di curiosità.xcodebuild dice che non contiene schema

Ho un progetto su cui ho lavorato e sempre creato dall'IDE XCode, e ha funzionato bene. Ora sto configurando Bamboo per costruire il progetto e come tale lo sto costruendo dalla riga di comando.

Il problema è che se controllo il mio codice da GIT e poi uso xcodebuild per costruirlo, dice che lo schema non può essere trovato, ma se apro il progetto, lo costruisce e se poi provo a ricostruirlo dalla riga di comando con lo stesso comando, funziona.

Che magia sta facendo XCode quando apro il progetto o sto facendo qualcosa di stupido, forse escludendo un file nel mio .gitignore che non dovrei?

+0

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ù –

risposta

8

Ok So che la sua 2 minuti più tardi, ma ho trovato un altro overflow dello stack che dice che il regime deve essere impostato condiviso ... Where does Xcode 4 store Scheme Data?

+0

Bello, buono per me, grazie – zest

172

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:

  1. Su una copia di lavoro pulita del codice, aprire l'area di lavoro del progetto.
  2. Scegli Schema> Gestisci schemi ... dal menu del prodotto.
  3. Viene visualizzato l'elenco di schemi definiti per il progetto.
  4. Individuare lo schema Bamboo sta tentando di eseguire
  5. 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.
  6. Fare clic su "OK" per chiudere il foglio Gestisci schemi.
  7. Un nuovo file .xcscheme è stato creato nel progetto in WorkspaceName.xcworkspace/xcshareddata/xcschemes.
  8. 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:

  1. Alcune operazioni automatiche che l'interfaccia utente Xcode si occupa magicamente non sono disponibili tramite la CLI di Xcodebuild.
  2. È 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)
  3. 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!

+0

Questo effettivamente ha corretto un errore xcodebuild casuale per me che restituiva NO errori ma un codice di uscita 65. Risulta che il contenitore è stato impostato per il progetto e non lo spazio di lavoro stesso, modificato e voilà, problema risolto. Grazie. –

+0

Grazie! Questa è esattamente la correzione che stavo cercando. – raidfive

+0

L'opzione MY Test and archive è disabilitata per questo motivo. Ho controllato il mio schema è condiviso. ancora non in grado di costruire attraverso bot.Io sono in grado di costruire localmente ma come ho detto che non posso archiviarlo. Pensi che sia relativo a questo problema – Alix

34

La maggior parte delle risposte suggerirebbe di condividere lo schema con Xcode, quindi di eseguire il commit delle modifiche al repository. Questo funziona, ovviamente, ma solo se si ha accesso al codice sorgente e si hanno i diritti per commettere modifiche e un paio di altre ipotesi.

Ma c'è un certo numero di "cosa se" di prendere in considerazione

  • Cosa se semplicemente non può modificare il progetto Xcode per qualche motivo?
  • Cosa succede se si crea automaticamente un nuovo schema sul server CI?
    Ciò accade in genere abbastanza spesso. Se si utilizza il framework di automazione del test, come Calabash, normalmente si finisce per duplicare un target esistente, che duplica automaticamente anche uno schema e il nuovo schema non è condiviso, anche se lo schema originale era.

Rubino & xcodeproj gemma

mi consiglia di utilizzare xcodeproj rubino gemma. Questo è uno strumento open source davvero interessante che può aiutarti ad automatizzare tonnellate di attività relative a Xcode.

Btw, questa è la gemma utilizzata da CocoaPods per scherzare con i progetti Xcode e gli spazi di lavoro.

Quindi installarlo

sudo gem install xcodeproj 

Poi scrivere un semplice script Ruby per ri-share tutti gli schemi, la gemma ha recreate_user_schemes metodo a tal fine

#!/usr/bin/env ruby 
require 'xcodeproj' 
xcproj = Xcodeproj::Project.open("MyProject.xcodeproj") 
xcproj.recreate_user_schemes 
xcproj.save 

non fa proprio copia i file dello schema dalla cartella dell'utente a xcshareddata/xcschemes, crea anche questi file per primi analizzando lo pbxproj file.

+1

Nel caso in cui qualcun altro si imbatta in questo, sembra che "recreate_user_schemes' non gestisca correttamente i target di test. Ho archiviato [un bug report su di esso] (https://github.com/CocoaPods/Xcodeproj/issues/139). –

+0

Ho bloggato su di esso. http://nsbogan.com/xcode/2014/05/29/share-xcode-schemes/. Sfortunatamente il problema con i test unitari non è ancora stato risolto. – i4niac

+0

bene, ho provato questa soluzione. Ma quando eseguo 'xcodebuild -project Finance.xcodeproj -scheme" Finance "-configuration Release clean archivio CODE_SIGN_IDENTITY =" My Identity "' Ho ottenuto 'Scheme è stato chiesto di creare e archiviare, ma il run destination non è una piattaforma di distribuzione e questa azione non avrebbe dovuto essere consentita '. Ma quando apro XCode tutto funziona perfettamente. L'azione "archivio" –

43

Debug la questione in questo modo:

correzione
xcodebuild -list 

o se si utilizza uno spazio di lavoro (ad esempio con cialde)

xcodebuild -workspace MyProject.xcworkspace -list 

Se schema non è elencata in questo modo:

+0

Rendere gli schemi condivisi permette loro di comparire in 'xcodebuild -list' ... grazie! –

3

Un motivo comune per cui manca lo schema è dimenticare di spingere il commit all'origine. Se ricevi un messaggio di schema mancante, devi prima verificare che lo schema sia condiviso, quindi verificare di aver impegnato le modifiche E di averle spinte sul server di origine.

0

Ottenuto lo stesso problema ma durante la creazione con xcode come sottoprogetto di quello principale. Sottoprogetto incorporato in xcode standalone - dopo che questo errore è scomparso.

0

Ho avuto questo errore durante l'implementazione di CI. La domanda sopra è identica ai miei problemi, tranne che sto usando lo stesso strumento CI di Gitlab. Puoi controllare se c'è un tale file in Bamboo.
Ho risolto il problema apportando alcune modifiche al file gitlab-ci.yml.
Dopo aver effettuato la condivisione scheme condividendo. In Xcode vai a Products>Scheme>Manage Scheme e controlla la condivisione da condividere.

Modifiche

Set absolute path everywhere.
eg. xcodebuild clean archive -archivePath /path/to/your/project/build/testDemo -scheme testDemo | xcpretty
here you need to change /path/to/your/project/ with your path and testDemo with your project name.