Recherche…
Remarques
Publier une version Release Track est en fait assez simple si vous comprenez a) que la commande publish-release requiert un fichier .json comme paramètre et b) à quoi ressemble ce fichier. C'est sans aucun doute l'obstacle le plus important pour démarrer, car il n'est pratiquement pas documenté.
Gardez à l'esprit que chaque paquet dans la version doit être publié et sur Atmosphere. Le fichier .meteor / versions d'une application est particulièrement adapté pour trouver tous les packages et versions nécessaires à la publication.
Après cela, il s'agit de déterminer ce que vous êtes prêt à prendre en charge, ce que vous voulez inclure, etc. Voici un diagramme de Venn partiel sur la manière dont fonctionne actuellement la version clinique. et devrait vous donner une idée générale de la façon dont nous procédons au processus de prise de décision de ce qui est inclus.
Pour plus de discussion, voir le sujet sur les forums Meteor:
https://forums.meteor.com/t/custom-meteor-release/13736/6
Utilisation de base
L'idée est qu'un responsable de la distribution souhaite exécuter quelque chose comme la commande suivante:
meteor publish-release clinical.meteor.rc6.json
Ce qui permettra ensuite aux utilisateurs de la distribution d'exécuter ceci:
meteor run --release clinical:[email protected]
Manifeste manifeste
Un manifeste de version est similaire à un fichier package.json NPM, dans la mesure où sa principale préoccupation est de spécifier une liste de packages Atmosphère et de fournir un peu de métadonnées sur cette liste de packages. Le format de base ressemble à ceci:
{
"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",
...
}
}
Personnalisation de l'outil Meteor
Si vous devez étendre l'outil meteor ou la ligne de commande, vous devrez créer et publier votre propre package meteor-tool. La documentation de Ronen est la meilleure pour ce processus:
http://practicalmeteor.com/using-meteor-publish-release-to-extend-the-meteor-command-line-tool/1
Il est facile de faire fonctionner une commande meteor helloworld, mais après cela, j'ai senti qu'il était plus facile de créer une application de nœud séparée pour tester les commandes. Quelle est la manière dont StarryNight a été créée. Il s'agit en quelque sorte d'un terrain de jeu et d'un bloc-notes pour les commandes avant d'essayer de les intégrer dans une version de l'outil météorite.
Extraire un manifeste de version de .meteor / versions
StarryNight contient un petit utilitaire qui analyse le fichier .meteor/versions une application et le convertit en un manifeste de version.
npm install -g starrynight
cd myapp
starrynight generate-release-json
Si vous ne souhaitez pas utiliser StarryNight, copiez simplement le contenu de votre fichier .meteor/versions dans le champ des packages de votre fichier manifeste. Assurez-vous de convertir en syntaxe JSON et d'ajouter des deux-points et des guillemets.
Affichage du manifeste de version pour une version spécifique
meteor show --ejson [email protected]
Publication d'un communiqué de presse
meteor publish-release --from-checkout
Récupération des derniers commits pour chaque package dans une version
Lors de la construction d'une piste de publication personnalisée, il est courant de conserver les paquets dans le répertoire /packages tant que sous-modules git. La commande suivante vous permet de récupérer tous les derniers commits pour les sous-modules de votre répertoire /packages en même temps.
git submodule foreach git pull origin master