web-dev-qa-db-fra.com

Comment puis-je supprimer un préfixe de {latest-tag} dans une recette de tableau de bord?

J'ai un recette du Launchpad qui ressemble à ceci:

# git-build-recipe format 0.4 deb-version {latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}
lp:kvantum master
nest packaging lp:~krisives/kvantum/+git/kvantum-packaging debian master

Cependant, en amont préfixe les numéros de version avec un V, ce qui amène le processus de création de package à se plaindre de ce que les versions doivent commencer par un nombre. L’auteur souhaite conserver ses noms de balises avec le préfixe V.

Hormis la modification manuelle de la changelog dans mon référentiel de conditionnement, existe-t-il un moyen de faire en sorte que la recette utilise automatiquement le {latest-tag} sans interrompre le processus de construction?

3
Kristopher Ives

Une solution de contournement consiste simplement à vous assurer que la partie de version en amont de votre version de package commence par un chiffre en l'insérant. Par exemple, vous pouvez utiliser:

# git-build-recipe format 0.4 deb-version 0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}

Notez que cela comparera moins que tout ce que vous avez déjà publié avec votre développement actuel, car par exemple, 0V1 est trié après V1. Si vous le devez, vous pouvez utiliser une époque (par exemple, 1:0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}) pour assurer un tri plus élevé que tout ce qui a été publié précédemment, mais cette bosse n'est pas réversible et doit donc être évitée dans la mesure du possible.

Pour plus d'informations:

Je ne vois aucune option dans la documentation permettant de faire quoi que ce soit avec la "dernière balise en amont" sauf pour l'incorporer dans la chaîne de la version finale, ni aucun autre moyen de récupérer la version en amont si la balise est le seul endroit en amont pour la déclarer. . Par conséquent, je pense que ma solution de contournement, ou quelque chose du genre, est votre seule option pour le moment, mais nous pouvons voir si quelqu'un d'autre a d'autres réponses.

Si la solution de contournement ne vous convient pas, les rapports de bogues contre git-build-recipe sont les bienvenus , y compris pour les demandes de fonctionnalités destinées à couvrir de nouveaux cas d'utilisation tels que celui-ci. Je ne peux pas vous dire quelle sera la réponse quant aux améliorations qui conviendraient en général, cependant. Une amélioration permettant de fournir une substitution basée sur les expressions rationnelles dans une extension pourrait être possible, par exemple, mais devrait probablement être implémentée de manière à garantir que le code malveillant ne puisse pas être exécuté sur l'hôte exécutant git-build-recipe malgré les apparences. une entrée de recette non fiable. Il serait probablement préférable de trouver un accord sur un bogue avant de tenter d'implémenter une telle fonctionnalité.

2
Robie Basak