J'ai un projet sauvegardé dans le référentiel Subversion et le compile avec Jenkins. Lorsque j'exécute la construction, Jenkins tire le projet dans le répertoire d'espace de travail. J'ai besoin de commettre un fichier changé de Jenkins Workspace en Subversion. Comment puis-je le faire ??
Merci pour des réponses ...
3 Réponses :
Pouvez-vous donner quelques détails de plus? Qu'est-ce que ce fichier est exactement et pourquoi doit-il être engagé dans le cadre de votre construction de Jenkins? Que construisez-vous (Java? C ++? .Net?) Et comment allez-vous la construire?
Normalement, vous ne devez rien mettre sous contrôle de version, sauf les fichiers source . C'est-à-dire que si vous pouvez le construire, vous ne devriez pas le mettre en version de version. Beaucoup de gens aiment commettre leur code bâti dans leur système de contrôle de la version, mais c'est généralement une grosse erreur. Les fichiers binaires sont beaucoup plus gros et rarement diff. Il en résulte un référentiel source à 90% de code compilé - presque tout cela obsolète. Ceci est particulièrement problématique avec la subversion qui n'a pas de moyen de supprimer (facilement) supprimer le code obsolète.
Jenkins a une fonctionnalité qui vous permet de Archive vos fichiers construits pour un accès facile. Nous utilisons cela tout le temps. Nous construisons notre code et le programme est disponible à Jenkins pour téléchargements. Encore meilleur, Jenkins supprimera les builds plus anciennes (vous pouvez enregistrer les builds de la dernière X ou enregistrer uniquement des immatricules de moins que x jours). Et si vous avez une version de candidature de version, vous pouvez verrouiller qui construit pour l'empêcher d'être supprimé.
Néanmoins, si vous insistez pour le faire, il y a plusieurs choses que vous pouvez faire et que vous devez faire attention à:
Lorsque vous avez la configuration de Jenkins pour créer automatiquement chaque modification et que vous avez commis une modification de votre système de contrôle de version, Jenkins le verra et commencer une nouvelle construction. Ensuite, Jenkins sauve le changement, voit le changement et fait une autre construction. Assurez-vous d'exclure les fichiers ou les répertoires de la considération de Jenkins lorsqu'il devrait faire une construction. Vous pouvez spécifier cela lorsque vous spécifiez l'URL de la caisse.
Contrairement à la plupart des systèmes de contrôle de la version, Subversion a été faite indépendante du client. Il y a une API réelle pour les clients. Le client de ligne de commande Sandversion standard n'est pas nécessaire à Jenkins, alors assurez-vous qu'il est installé. Assurez-vous d'installer un client compatible avec les Jenkins intégrés au client SVNKIT. Cela est particulièrement vrai depuis la subversion 1.6, 1.7 et 1.8 tous prennent un format client différent.
Vous pouvez ajouter plusieurs étapes construction à votre construction à Jenkins. Ajoutez simplement un nouveau script shell ou une étape de script de lot, puis ajoutez-en un Comme je l'ai déjà dit, 99,99999% du temps, vous ne devriez pas utiliser Jenkins pour commettre des changements informés. Je suis sûr que la raison de 0,0001% existe quelque part , mais je ne l'ai jamais vu. Si vous souhaitez effectuer des fichiers construits universellement accessibles à vos autres projets, utilisez la capacité de Jenkin à archiver des fichiers construits.
Si un produit Jenkins est nécessaire est nécessaire pour une autre version, vous pouvez utiliser Copier le plug-in artefact pour copier un artefact de construction vers un autre travail, puis tirer cet emploi. Encore mieux, utilisez un système de référentiel de libété. En Java, vous pouvez utiliser un référentiel de libérations Maven comme Nexus ou Artefactory. Pour utiliser et déployer des artefacts vers ce référentiel, vous pouvez utiliser Ivy ou Maven ou Gradle. Si vous construisez .net, regardez Nuget.
SVN COMMT -M "Commentaire d'une sorte" étape. Il est assez simple de faire une fois que vous avez pris soin des deux premiers points. Cependant, pensez-vous soigneusement pourquoi vous faites cela.
Une des raisons que j'ai vues à commettre dans une version consiste à incrémenter la version de libération dans le cadre d'une version automatisée. Certainement, il existe d'autres moyens de faire cela et d'autres outils, mais il est plus courant que 1 sur 10 ^ 6 :)
Il n'y a aucune raison de vérifier quoi que ce soit dans ce cas. Vous avez un fichier contenant une chaîne de modèle qui est remplacée par un numéro de version. Dans Subversion, vous pouvez utiliser le numéro de révision Subversion. Encore mieux, nous utilisons le nom du poste de Jenkins et le numéro de construction, afin que nous puissions revenir à la construction de Jenkins qui me montre des choses comme des données de test et nous aide à retrouver l'histoire. Sinon, tout ce que vous faites est de créer des milliers de révisions de subversion qui ne contiennent absolument aucune information utile d'historique. Vous faites un svn journal et 50% des modifications énumérées sont dues à la construction.
Je ne vais certainement pas suggérer de commettre à chaque construction de CI. De toute évidence, nous utilisons une terminologie différente, version build! = Build. Dans le cas que je décris, il y a un public face numéro de version « marketing » qui, chaque pas version build.
Je suis sûr que cette question est valable pour certains cas d'utilisation et tout cet enseignement n'est pas nécessaire. Ou peut-être être pour quelqu'un, je le mettais comme une note latérale.
Vous pouvez utiliser soigneusement:
svn commit -username someuser -password %injected_password%
En réalité, il devrait être svn commet-nom - insutilisateur -sutilisateur --password% injected_password% (= Double tirets pour options)
Dans le cadre de votre travail, vous pouvez exécuter un script (Bash) qui pourrait exécuter
svn commettez .