Comment supprimer une version spécifique d'un package sur un flux TeamCity Nuget?
Est-ce que quelqu'un sait supprimer une version spécifique d'un paquet sur un flux TeamCity Nuget?
Ceci est maintenant pris en charge via l'interface utilisateur Web
Supprimez simplement la construction incriminée en l'ouvrant et en choisissant Actions> Remove. Cela supprime la construction de la liste dans TeamCity, ainsi que tous les artefacts de construction de cette construction spécifique du flux Nuget .
Je sais que cela a été demandé il y a longtemps, mais je rencontre toujours ce problème de temps en temps et j'oublie toujours comment le faire. Je me suis donc dit que j'afficherais ma solution, ce qui pourrait être un peu plus facile, selon moi. à elle).
En gros, j’ai exécuté une version TeamCity qui a malheureusement créé une version complète d’un package tiers que j’ai essayé de recréer, mais avec quelques modifications. Cela n'a pas fonctionné, mais cela signifiait que ce paquet duff m'était toujours présenté dans le gestionnaire de paquets et qu'il en resterait ainsi jusqu'à ce que la 3ème partie publie une version plus récente. En tant que tel, je voulais supprimer le paquet du serveur TeamCity Nuget et la seule façon de le faire était de supprimer la construction qui supprimerait également les artefacts (le paquet duff Nuget dans ce cas).
Maintenant, je ne pouvais pas voir un moyen de supprimer la construction, sauf avec l'API REST, donc c'est ce que j'ai utilisé (j'espère que je ne suis pas stupide et qu'il existe un moyen simple de supprimer des versions de l'interface utilisateur). . J'ai utilisé fiddler pour générer la commande DELETE. Ceci a été réalisé en postant simplement une demande de suppression similaire à celle que j'ai montrée ci-dessous:
Depuis le violoniste, allez dans la fenêtre Composer. Sélectionnez 'DELETE' au lieu de 'GET' et entrez votre URL TeamCity dans le formulaire ci-dessous:
http://<server>:<port>/httpAuth/app/rest/builds/<build ID>
L'identifiant de construction peut être trouvé en inspectant simplement l'URL lorsque vous sélectionnez la construction que vous souhaitez supprimer de TeamCity (recherchez le numéro après le paramètre de requête 'buildId'). La seule autre étape a été d'ajouter l'en-tête d'autorisation à la commande. Entrez les informations suivantes sur la ligne située sous "User-Agent" dans la fenêtre En-têtes de demande.
Authorization: Basic (Username:Password encoded as base64)
Pour encoder votre nom d'utilisateur/mot de passe en base64, allez à Outils-> Texte Wizard dans fiddler et entrez vos détails TeamCity dans ce format - Nom d'utilisateur: Mot de passe. Enfin, vous devez sélectionner le bouton "Exécuter" et, si tout se passe bien, la construction sera supprimée en même temps que le paquet Nuget.
Cela a fonctionné pour moi, mais évidemment, soyez prudent lorsque vous faites tout cela, car vous ne voulez pas supprimer la mauvaise construction. Il peut être prudent de sauvegarder/d'instantané votre serveur TeamCity en premier.
J'espère que ça aide quelqu'un.
Tout d'abord, il semble que la suppression de packages NuGet ad hoc est pas directement prise en charge dans TeamCity pour le moment. Il existe un problème ouvert avec JetBrains à ce sujet, mais aucun correctif n’est actuellement prévu. Cela dit, nous avons mis au point une solution de contournement qui nous a permis de résoudre notre problème spécifique et qui pourrait vous aider.
Nous avions une série de fichiers nupkg qui utilisaient une version incorrecte (accélérée). Ainsi, ils semblaient être "plus récents" que les paquets que nous créons maintenant. Sans moyen de supprimer uniquement les versions incorrectes, nous avons défini la stratégie "Nettoyer les artefacts" de chaque configuration de construction de TeamCity sur une courte fenêtre (2 jours) et exécuté le nettoyage. Pour ce faire, vous aurez besoin des privilèges d’administrateur système.
Cela a supprimé tous les artefacts un jour plus vieux que le dernier et a nettoyé tous nos mauvais paquets. Nous l'avons vérifié via la commande List de la ligne de commande NuGet. Les paquetages les plus récents étant corrects, nous ne faisons plus de publicité pour les bons paquets dans notre flux NuGet.
Certes, il s’agit d’une option de «précision nucléaire» qui risque de ne pas convenir à tout le monde. J'espère que TeamCity supportera pleinement l'API de ligne de commande NuGet dans un avenir proche.
C’est maintenant la troisième fois que je trouve ce billet, car j’ai un problème similaire. Il s'avère que le ticket avec jetbrains a été fermé il y a longtemps - et TeamCity maintenant (au moins notre version 9.1) le soutient directement en ouvrant les détails d'un build spécifique, cliquez sur le menu déroulant "Actions", puis sélectionnez "Retirer...". Cela supprimera la construction de TeamCity ainsi que les artefacts du référentiel de packages de nuget - éliminant ainsi complètement la nécessité d'appeler l'api REST de manière légèrement alambiquée.
Ayant posté ceci, je pourrais même m'en souvenir moi-même, la prochaine fois que je devrais le faire.
J'ai créé un script PowerShell dans le sens de la réponse de King Rogers.
Enregistrez ce script sous tc_deletebuild.ps1 ...
param($build, $teamcityhost, $username, $password)
$encodedcredentials = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($username+":"+$password))
Invoke-WebRequest -Uri "http://$teamcityhost/httpAuth/app/rest/builds/id:$build" -Method Delete -Headers @{"Authorization"="Basic $encodedcredentials"}
... et exécuter de powershell avec
.\tc_deletebuild.ps1 <buildid> <Host> <username> <password>
Etendre la réponse de King Roger ... l'extension client chromée postman REST est un moyen facile de le réaliser avec peu d'outils.
> HTTP GET to http://servername:port/httpAuth/app/rest/builds/
La sortie ressemblera à
<builds count="100" nextHref="/httpAuth/app/rest/builds?count=100&start=100">
<build id="48459" number="1.0.187-nightly" ... etc
Recherchez dans la sortie votre identifiant de build, sur la même balise que le numéro de build que vous voyez dans teamcity, puis
> HTTP DELETE to http://servername:port/httpAuth/app/rest/builds/*theid*
Je n'avais pas besoin d'étiquettes d'autorisation ni d'autres en-têtes, peut-être que j'étais connecté à teamcity dans une autre fenêtre ou que nous avons configuré teamcity pour qu'il soit ouvert en interne, mais vous devrez peut-être les insérer dans l'URL et les en-têtes.
Dans le prolongement de la réponse de King Roger, j'ai utilisé une manière légèrement différente de composer la demande dans Fiddler. J'ai envoyé une requête Get à une version particulière de Teamcity et saisi les en-têtes http dans l'outil Chrome Developer. Copiez-les et collez-les dans la boîte des en-têtes de demande de Fiddler. De cette façon, je n'ai pas eu à encoder le nom d'utilisateur et le mot de passe.