La label de git no debería fallar si la label ya está en la confirmación que quiero labelr

Parte de nuestro CI es labelr nuestro repository utilizando la versión especificada en un file version.txt . Simplemente hacemos:

 git tag `cat version.txt` 

Como no tenemos forma de boost automáticamente la versión (no hay manera de saber si estamos haciendo una versión mayor o menor), la actualización del file version.txt se deja al desarrollador individual. Lo que significa que los errores pueden ocurrir y ocurren.

Lo que queremos es:

1. si la versión se ha actualizado, el repository debe labelrse e implementarse.
2. si la versión no se ha actualizado, el ciclo de IC debe fallar.
3. pero si el ciclo de CI se reinicia manualmente, esto debería ejecutarse sin problemas

El requisito 3 podría cumplirse fácilmente si la git tag no estuviera fallando siempre que quiera labelr la confirmación actual con una label que ya tenga.

Es decir, la git tag 1.2.3 falla si la label 1.2.3 ya está en una confirmación anterior (buena), pero también falla si está en la confirmación que quiero labelr (incorrecta).

¿Hay alguna manera de decirle a la git tag no falle si quiero labelr la confirmación actual con una de las tags que ya tiene?

De lo contrario, tendré que implementar esta característica yo mismo, obteniendo el compromiso al que se refiere la label, y verificándolo contra la confirmación actual en HEAD.

 git tag -l --points-at HEAD <tag> 

 $ git tag -d <tag-name> # delete the tag from local $ git push origin :refs/tags/<tag-name> # delete a tag from remote $ git tag <cat version.txt> # give a new tag on current commit $ git push --tags # push tag