Auto: Message de validation de bump personnalisé

Je préférerais peut-être pas de commits de bosse (comme semantic-release fait):

{
  "skipBumpCommit": true
}

Avec les commits bump désactivés, la dernière version de NPM est la source de vérité (ou peut-être qu'elle fonctionne déjà de cette façon ?) et le champ "version" dans package.json peut être défini sur 0.0.0-development ou similaire.

est-ce que skip CI est différent sur travis ? sans cela dans vos messages de validation, vous pouvez facilement tomber dans une boucle

auto utilisera la version locale et la version publiée et choisira la version la plus élevée pour éviter les erreurs npm. Est-ce suffisant ?

est-ce que skip CI est différent sur travis ? sans cela dans vos messages de validation, vous pouvez facilement tomber dans une boucle

Je ne suis pas vraiment sûr. Si cela est requis dans l'en-tête de validation, qu'il en soit ainsi. ??

auto utilisera la version locale et la version publiée et choisira la version la plus élevée pour éviter les erreurs npm. Est-ce suffisant ?

Oh vraiment? Joli. Aucun commit bump n'est-il créé dans ce cas ?

Non, dans ce cas, nous supprimons la version publiée car vous pouvez publier sur une ancienne version.

J'ai du mal à visualiser comment skipBumpCommit fonctionnerait ou à quoi ressemblerait le résultat final. Pour exécuter shipit vous devez modifier la version d' une manière ou d'

Que pensez-vous de shipit sautant le commit bump lorsque la version dans package.json est quelque chose comme 0.0.0-development ?

1. Le paquet commence à 0.0.0-développement

2. vous exécutez version il renvoie le bump basé sur les PRs, il renvoie n'importe quoi (patch, minor, major) - disons que c'est patch

3. Création du journal des modifications - (0.0.0-development => 0.0.0). Mais vous ne voulez pas que cela se produise ? Au lieu d'ajouter sous le titre du journal des modifications « 0.0.0-development » ?

4. publier le temps des crochets - il faudrait 0.0.0-développement => 0.0.0 et publier. mais vous voulez que development soit détecté et sautez l'étape de publication tous ensemble

5. faire une version github - Au lieu de créer une nouvelle version, mettez à jour l'ancienne avec les nouveaux commits

6. Le paquet reste à 0.0.0-développement jusqu'au ??? tandis que les changements s'accumulent

Deux options si c'est ce que vous voulez :

1. N'exécutez simplement pas auto shipit jusqu'à ce que vous vouliez commencer à publier et à publier. Ajoutez toujours les étiquettes à vos PR. Lorsque vous êtes prêt, ajoutez auto shipit à votre processus CI et il inclura tous les PR de labels dans votre première version.

2. Écrire un plugin. Ce comportement est assez unique et n'est pas vraiment conforme à la façon dont npm gère les versions. Je pense que vous pourriez faire un plugin pour accomplir ce genre de choses. Bien que je devrais probablement ajouter un crochet ou deux pour que vous puissiez les utiliser.

Un package avec une version de 0.0.0-development indique ce qui suit :

• La version NPM la plus élevée publiée est considérée comme la "version actuelle"
• Le version dans package.json ne doit jamais être modifié

Lorsqu'une nouvelle version de NPM doit être publiée, Auto doit incrémenter la "version actuelle" à l'aide de npm version $(auto version) .

Le changelog utilise la "version actuelle" de NPM (au lieu de package.json ).

Comme toujours, une nouvelle version de Github est créée pour chaque version de NPM.

Suis-je assez clair ?

La version dans package.json ne doit jamais être modifiée

Pour publier de nouvelles versions sur NPM, vous devez modifier cela. La seule façon d'incrémenter la "version actuelle" et de ne jamais changer la version locale serait de :

• le remplacer par la version actuelle (NPM)
• faire la bosse
• le changer en arrière
• mais puisque c'est la balise qui ferait bosse la version actuelle ???

Je suis presque sûr de comprendre votre cas d'utilisation.

une. vous ne voulez pas publier un tas de versions pendant que vous développez une fonctionnalité sur plusieurs PRS
b. une fois qu'une nouvelle version doit être publiée, vous voulez que tous les changements soient inclus

À mes yeux, nous vous donnons déjà deux façons de le faire :

1. utilisez onlyPublishWithReleaseLabel . les nouvelles versions ne sont pas créées tant que vous n'avez pas ajouté cette étiquette. Vous pouvez donc regarder n'importe quel PR/code sans l'étiquette VERSION-development

2. lorsque vous fusionnez des PR pour la grande fonctionnalité, utilisez skip-release jusqu'à ce que vous soyez prêt pour une version, puis fusionnez simplement un PR. La nouvelle version contient tous les PR ignorés. Dans ce cas, vous pouvez ajouter l'étiquette skip-release comme signifiant que votre version est VERSION-development

En quoi cela diffère-t-il du comportement que vous souhaitez ?

Il me semble que cela se résume à : vous voulez ajouter -development à votre version pour commencer à sauter des versions et la supprimer lorsque vous êtes prêt pour que toutes les modifications soient publiées en même temps.

pour accomplir ma dernière phrase, vous pourriez probablement créer un plugin qui utilise beforeShipit pour vérifier la présence de -development dans la version et renvoie une erreur si elle est présente. Cela empêcherait shipit d'avancer jusqu'à ce que vous supprimiez -development .

Le seul problème que je vois avec cela est qu'il échouerait également le travail CI.

Interprétation intéressante, mais pas tout à fait ce que je voulais. ??

Je décris essentiellement comment fonctionne semantic-release .

J'aurais dû dire "La version dans package.json n'est modifiée que temporairement pour que npm publish réussisse" (au lieu de "La version dans package.json ne doit jamais être modifiée"). Tout ce que j'essaie de faire, c'est d'éviter complètement le commit bump. :)

D'accord, l'état dans lequel vous vous retrouveriez est :

repo: n'a jamais que la version 0.0.0-dev

npm: A la vraie version tout le temps (c'est ce qui est utilisé pour n'importe quoi)

correct?

Un peu comme

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

Ouais, ça a l'air bien !

auto v4.0.0 nous voici lol. On dirait que je vais devoir diviser le crochet publish . Ce sera un autre plugin

Si vous le souhaitez, vous pouvez intégrer cette fonctionnalité dans Auto pour le moment et attendre de diviser le crochet publish jusqu'à ce qu'un autre plugin en ait également besoin. ??

Cela devrait être possible via le plugin maintenant avec # 247 (la capacité semver). Le message de validation nécessite un peu de changements de configuration et ne vous rapporte pas grand-chose. Fermeture mais ouverte aux RP !