Ricerca…


Osservazioni

Pubblicare una traccia di rilascio è in realtà piuttosto semplice se si capisce a) che il comando di rilascio della pubblicazione richiede un file .json come parametro e b) come si presenta il file. Questo è sicuramente il più grande ostacolo per iniziare, perché è praticamente non documentato da nessuna parte.

Tieni presente che ogni pacchetto della versione deve essere pubblicato e su Atmosphere. Il file .meteor / versions di un'app è particolarmente adatto per trovare tutti i pacchetti e le versioni necessari che dovrebbero essere inclusi nella versione.

Dopodiché, si tratta di capire cosa sei disposto a supportare, cosa vuoi includere, ecc. Ecco un diagramma di Venn parziale di ciò che sta attualmente lavorando su Clinical Release; e dovrebbe darti un'idea generale di come stiamo andando nel processo decisionale di ciò che viene incluso.

Per ulteriori discussioni, consultare l'argomento sui forum di Meteor:
https://forums.meteor.com/t/custom-meteor-release/13736/6

Uso di base

L'idea è che un mantenitore di distro voglia eseguire qualcosa come il seguente comando:

meteor publish-release clinical.meteor.rc6.json

Che consentirà quindi agli utenti della distribuzione di eseguire questo:

meteor run --release clinical:[email protected]

Rilascia Manifest

Un manifest di rilascio è simile a un file package.json NPM, in quanto è di primaria importanza specificare un elenco di pacchetti Atmosphere e fornire un po 'di metadati relativi a tale elenco di pacchetti. Il formato base ha questo aspetto:

{
  "track":"distroname:METEOR",
  "version":"x.y.z",
  "recommended": false,
  "tool": "distroname:[email protected]",
  "description": "Description of the Distro",
  "packages": {
    "accounts-base":"1.2.0",
    "accounts-password":"1.1.1",
    ...
  }
}

Personalizzazione dello strumento Meteor

Se è necessario estendere lo strumento Meteora o la riga di comando, è necessario creare e pubblicare il proprio pacchetto di meteor-tool. La documentazione di Ronen è la migliore in circolazione per questo processo:

http://practicalmeteor.com/using-meteor-publish-release-to-extend-the-meteor-command-line-tool/1

È facile ottenere il comando di un meteorite di helloworld, ma dopo ho pensato che fosse più semplice creare un'app di nodo separata per testare i comandi. Ecco come è nata StarryNight. È qualcosa di un palcoscenico e di un blocco per i comandi prima di provare a metterli in una versione dello strumento meteorico.

Estrazione di un Manifesto di rilascio da .meteor / versioni

StarryNight contiene una piccola utility che analizza il file .meteor/versions di un'applicazione e lo converte in un Manifesto di rilascio.

npm install -g starrynight
cd myapp
starrynight generate-release-json

Se non desideri utilizzare StarryNight, copia semplicemente il contenuto del file .meteor/versions nel campo packages del file manifest. Assicurati di convertire in sintassi JSON e aggiungi due punti e virgolette.

Visualizzazione del Manifesto di rilascio per una versione specifica

meteor show --ejson [email protected]

Pubblicazione di una versione dalla cassa

meteor publish-release --from-checkout

Recupero degli ultimi commit per ogni pacchetto in una versione

Quando si costruisce una traccia di rilascio personalizzata, è normale tenere i pacchetti nella directory /packages come sottomoduli git. Il seguente comando consente di recuperare tutti gli ultimi commit per i sottomoduli nella directory /packages allo stesso tempo.

git submodule foreach git pull origin master


Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow