TL; DR - Existe-t-il une tâche de pipeline Azure DevOps pour le formatage du code dans le cadre du processus de génération? Je n'ai pas pu en trouver un et je le trouverais vraiment utile.
Mon équipe utilise l'extension gratuite CodeMaid Visual Studio pour "embellir" (format) Code C #. Bien que l'extension fonctionne bien, il existe plusieurs limitations pour se fier aux développeurs pour formater leur propre code dans Visual Studio:
Je pense qu'une bien meilleure solution serait d'avoir une tâche de pipeline dans Azure DevOps qui exécute un outil comme Code Maid dans le cadre du processus de construction. Cela garantirait qu'aucun code n'entre dans le contrôle de code source dans un état laid et non formaté et garantirait que tout le code est formaté selon la norme activée dans le cadre de la construction.
3 Réponses :
Vous pouvez exécuter une commande native sur la ligne de commande qui est au dotnet-format qui réalisera ce que vous voulez. Vous pouvez l'exécuter dans votre pipeline. Il doit être installé et peut donc ajouter une surcharge à vos builds.
Installez en utilisant la commande suivante:
dotnet format --fix-style warn
Ensuite, pour formater le projet ou la solution en cours directement dans le courant utilisez:
dotnet format
Pour corriger les avertissements de l'analyseur de style de code, vous pouvez également utiliser cette commande:
dotnet tool install -g dotnet-format
La liste complète des commandes disponibles se trouvent sur les projets GitHub .
Les outils personnalisés peuvent-ils être installés sur des serveurs cloud Azure DevOps? À part les tâches en cours d'exécution, je ne pensais pas que l'on pouvait installer une application personnalisée sur un serveur de build.
Oui, vous pouvez les charger dans le conteneur à l'aide d'une étape du pipeline. C'est l'outil que j'utilise dans mes pipelines. L'utilitaire de ligne de commande dotnet est déjà chargé, vous n'ajouterez que l'outil, pas tout le binaire.
À mon avis, le commit déclenchant la construction devrait être immuable. Si vous mettez quelque chose pour formater le code, vous allez devoir pousser un nouveau commit dans le dépôt pour que le changement soit vraiment incorporé. Alors, allez-vous simplement déclencher à nouveau la construction de CI?
Ma suggestion pourrait être d'automatiser l'exécution de l'outil de mise en forme dans le cadre du pipeline. S'il trouve des modifications qui seraient apportées (ce qui signifie que quelqu'un n'a pas exécuté l'outil avant de pousser vers la télécommande), échouez simplement la construction. Faire une construction réussie une exigence pour fusionner une demande de tirage. Les gens feront la queue s'ils ne peuvent pas terminer leur travail selon le processus normal. Les paramètres que vous configurez pour cela dans le pipeline seront la norme, de sorte que les développeurs choisissent des onglets ou des espaces. :)
Code Maid n'est peut-être pas la meilleure option pour cela. Je vois un ticket github ouvert à propos de ce n'est pas vraiment génial pour l'automatisation de la ligne de commande. Il est assez étroitement couplé à Visual Studio. De plus, cela peut représenter un effort assez important, mais j'imagine que vous voudriez que quelqu'un exécute le formatage sur la source complète, afin que tout le monde puisse commencer à partir du vert.
Je suis presque sûr d'avoir fait exactement cette chose en utilisant Resharper.
Plus j'y pensais, plus je suis d'accord avec toi Matt. C'est-à-dire que changer le format du code lors de la construction nécessiterait un nouveau commit Git, ce qui serait étrange. Avoir une sorte de "porte" sur un pipeline qui échoue le pipeline s'il détecte que le formatage n'a pas été exécuté serait idéal. J'utilise actuellement CodeMaid simplement parce que c'est gratuit et que mon client actuel ne paiera pas pour des licences pour quelque chose comme Resharper.
Vous pouvez faire un examen de StyleCop si vous rencontrez des problèmes pour exécuter CodeMaid sur un pipeline ou dans un test unitaire codé. Croyez qu'il est open source et fonctionne bien avec c #.
Je pense qu'une bien meilleure solution serait d'avoir une tâche de pipeline dans Azure DevOps qui a exécuté un outil tel que Code Maid dans le cadre de la construction traiter. Cela garantirait qu'aucun code n'entre dans le contrôle de code source dans un état laid, non formaté et garantirait que tout le code est formaté pour quelle que soit la norme activée dans le cadre de la construction.
Azure Devops n'a pas une telle tâche de pipeline pour formater les fichiers pendant l'exécution du pipeline. Et il n'est pas recommandé d'apporter des modifications à git repo pendant l'exécution du pipeline.
Le scénario normal est:
1 Nous avons git repo hébergé dans Azure Devops et quelqu'un développe localement avec la branche dev .
2.Quelqu'un apporte des modifications et valide les modifications (modifier le code ou ajouter des fichiers sources supplémentaires)
3.Synchronisez les commits avec le dépôt distant, la modification du dépôt distant déclenche l'exécution du pipeline correspondant. (CI pour vérifier si le code est correct, CD pour déployer de nouvelles modifications)
Maintenant que vous modifiez les fichiers source pendant le pipeline, cela provoquera un déclenchement sans fin à moins que vous ne désactiviez le CI. À la place, vous pouvez utiliser Politique de branche pour améliorer le processus, vous pouvez définir la stratégie de branche pour la branche principale. Pour que tout changement via PR à master soit approuvé par les examinateurs. Et les réviseurs spécifiques peuvent vous aider à vérifier le format du code.