web-dev-qa-db-fra.com

Comment publier un package NPM à partir du pipeline de génération CI et toujours automatiser la gestion des versions?

Je n'arrive pas à voir la forêt derrière les arbres. Je veux avoir un pipeline CI simple qui construit et publie un package NPM. J'utilise appveyor, mais je ne pense pas que mon problème lui soit spécifique. Je veux simplement que mon script CI exécute quelque chose comme ceci:

git clone "https://git_repo_url" .
npm run build
npm run test
npm version patch --git-tag-version
npm publish -tag beta

Le problème est:

  • Si je ne fais pas le npm version patch étape, la publication échouera avec le feed already contains the package 'abc' at version 'x.y.z' Erreur.

  • Si je fais cette étape, je devrais repousser le nouveau commit (le changement de version) vers le dépôt git. Sinon, il échouera comme ci-dessus la prochaine fois que moi ou quelqu'un d'autre le construira. Pourtant, je n'ai pas envie de faire git Push dans le pipeline back-end serait la bonne chose.

  • Enfin, si ce script CI construit simplement le package NPM sans le publier, comment puis-je le consommer dans d'autres projets qui en dépendent?

Quelles sont les méthodes standard de l'industrie pour y parvenir?

Par exemple, si j'ai besoin de tester une version de non-production de mon package avec un autre projet, dois-je faire mon script CI pour patcher _ package.json avec une version unique et compatible compatible semver (sans la valider), puis la publier avec une balise npm qui correspondrait à mon nom de branche git? Est-ce que c'est une bonne idée?

6
avo

Je serais toujours très intéressé par les meilleures pratiques DevOps pour publier des packages NPM internes/par version avec CI pendant le cycle de développement normal.

généralement, le responsable du projet remplace la version, en fonction des fonctionnalités et/ou des modifications apportées au projet.

par exemple:

  • si les changements cassent les changements (non compatibles avec les backwords), le mainteneur bumpera la version majeure
  • si les changements sont de nouvelles fonctionnalités (fonctions d'assistance, refactoring, etc.), le mainteneur bumpera la version mineure

il existe de nombreuses approches pour la version du patch . en voici 2:

  1. git pre-Push hook, qui contourne le patch et le valide dans le référentiel, ce qui élimine le système build\ci modifiant le code source du projet
  2. utilisez le numéro de build dans le système build\ci comme patch nombre, en ignorant la version du correctif validée dans le référentiel
1
Mr.