Si vous possédez ou gérez un référentiel GitHub et que vous avez déjà poussé un paquet de celui-ci vers PyPI et/ou Fedora, vous savez que cela nécessite un travail supplémentaire en utilisant l'infrastructure Fedora.
Bonne nouvelle :nous avons développé un outil appelé release-bot qui automatise le processus. Tout ce que vous avez à faire est de déposer un problème dans votre référentiel en amont et release-bot s'occupe du reste. Mais ne nous précipitons pas. Tout d'abord, regardons ce qui doit être mis en place pour que cette automatisation se produise. J'ai choisi la meta-test-family référentiel en amont à titre d'exemple.
Fichiers de configuration pour release-bot
Il existe deux fichiers de configuration pour release-bot :conf.yaml et release-conf.yaml .
conf.yaml
conf.yaml doit être accessible lors de l'initialisation du bot ; il spécifie comment accéder au référentiel GitHub. Pour montrer cela, j'ai créé un nouveau dépôt git nommé mtf-release-bot , qui contient conf.yaml et les autres fichiers secrets.
repository_name :nom
repository_owner :propriétaire
# https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/
github_token :xxxxxxxxxxxxxxxxxxxxxxxxx
# temps en secondes lors de la recherche de nouvelles versions
refresh_interval :180
Pour le cas de la famille de méta-tests, le fichier de configuration ressemble à ceci :
repository_name :meta-test-family
repository_owner :fedora-modularity
github_token :xxxxxxxxxxxxxxxxxxxxx
refresh_interval : 180
release-conf.yaml
release-conf.yaml doit être stocké dans le référentiel lui-même ; il spécifie comment faire les versions de GitHub/PyPI/Fedora.
# liste des principales versions de Python pour lesquelles le bot construira des roues distinctes pour
python_versions :
- 2
- 3
# facultatif :
changelog :
- Exemple d'entrée du journal des modifications
- Une autre entrée du journal des modifications
# il s'agit d'informations sur la paternité du journal des modifications
# si ce n'est pas défini, la personne qui a fusionné le PR de version sera utilisée comme auteur
author_name :John Doe
author_email :[email protected]
# s'il faut publier sur fedora. False par défaut
fedora :false
# liste des branches Fedora sur lesquelles le bot doit publier. Master est toujours implicite
fedora_branches :
- f27
Pour le cas de la famille de méta-tests, le fichier de configuration ressemble à ceci :
python_versions :
- 2
fedora :vrai
fedora_branches :
- f29
- f28
trigger_on_issue :vrai
Fichier de configuration PyPI
Le fichier .pypirc , stocké dans votre mtf-release-bot référentiel privé, est nécessaire pour télécharger la nouvelle version du package dans PyPI :
[pypi]
nom d'utilisateur =phracek
mot de passe =xxxxxxxx
Clé SSH privée, id_rsa , que vous avez configuré dans FAS.
La structure finale du dépôt git, avec conf.yaml et les autres, ressemble à ceci :
$ ls -la
total 24
drwxrwxr-x 3 phracek phracek 4096 Sep 24 12:38 .
drwxrwxr-x. 20 phracek phracek 4096 24 septembre 12:37 ..
-rw-rw-r-- 1 phracek phracek 199 24 septembre 12:26 conf.yaml
drwxrwxr-x 8 phracek phracek 4096 24 septembre 12 :38 .git
-rw-rw-r-- 1 phracek phracek 3243 24 septembre 12:38 id_rsa
-rw------- 1 phracek phracek 78 24 septembre 12:28 .pypircExigences
Plus de ressources Python
- Qu'est-ce qu'un IDE ?
- Aide-mémoire :Python 3.7 pour les débutants
- Meilleurs frameworks d'interface graphique Python
- Télécharger :7 bibliothèques PyPI essentielles
- Développeurs Red Hat
- Dernier contenu Python
La publication vers PyPI nécessite le package wheel pour Python 2 et Python 3, installez donc requirements.txt avec les deux versions de pip. Vous devez également configurer vos informations de connexion PyPI dans $HOME/.pypirc , comme décrit dans la documentation PyPI. Si vous publiez sur Fedora, vous devez avoir un ticket Kerberos actif pendant l'exécution du bot, ou spécifier le chemin vers le fichier keytab Kerberos avec -k/–keytab . Aussi, fedpkg nécessite que vous ayez une clé SSH dans votre trousseau de clés que vous avez téléchargé sur FAS.
Comment déployer release-bot
Il existe deux façons d'utiliser release-bot :en tant qu'image Docker ou en tant que modèle OpenShift.
Image Docker
Construisons l'image en utilisant le s2i commande :
$ s2i build $CONFIGURATION_REPOSITORY_URL usercont/release-bot app-name
où $CONFIGURATION_REPOSITORY_URL est une référence au dépôt GitHub, comme https://
Regardons les images Docker :
$ Docker images
Étiquette de référentiel ID d'image de l'image créée
MTF-RELAVE-BOT Dernier 08897871E65E Il y a 6 minutes 705 Mo
Docker.io/usercont/release-Bot il y a le plus 5B34AA670639 9 jours 705 Mo
Essayons maintenant d'exécuter le mtf-release-bot image avec cette commande :
$ docker run mtf-release-bot
---> Configuration de la clé ssh...
Agent pid 12
Identité ajoutée :./.ssh/id_rsa (./. ssh/id_rsa)
12:21:18.982 configuration.py DEBUG Configuration chargée pour fedora-modularity/meta-test-family
12:21:18.982 releasebot.py INFO release-bot v0.4.1 rapport pour duty !
12:21:18.982 github.py DEBUG Récupération de release-conf.yaml
12:21:37.611 releasebot.py DEBUG Aucun PR de version fusionné trouvé
12:21:38.282 releasebot. py INFO Nouveau problème avec la version : 0.8.5
12:21:42.565 releasebot.py DEBUG Aucun autre problème en suspens trouvé
12:21:43.190 releasebot.py INFO Création d'un nouveau PR pour la version de version 0.8.5 basée sur un problème.
12:21:46.709 utils.py DEBUG ['git', 'clone', 'https://github.com/fedora-modularity/meta-test-family. git', '.']
12:21:47.401 github.py DEBUG {"message":"Branch not found","documentation_url":"https://developer.github.com/ v3/dépôt/branche hes/#get-branch"}
12:21:47.994 utils.py DEBUG ['git', 'config', 'user.email', '[email protected]']
12:21:47.996 utils.py DEBUG ['git', 'config', 'user.name', 'Release bot']
12:21:48.009 utils. py DEBUG ['git', 'checkout', '-b', '0.8.5-release']
12:21:48.014 utils.py ERREUR Aucun fichier de version trouvé. Abandon de la mise à jour de la version.
12:21:48.014 utils.py AVERTISSEMENT Aucun CHANGELOG.md présent dans le référentiel
[Errno 2] Aucun fichier ou répertoire de ce type :'/tmp/tmpmbvb05jq/CHANGELOG.md'
12:21:48.020 utils.py DEBUG ['git', 'commit', '--allow-empty', '-m', '0.8.5 release']
[0.8.5-release 7ee62c6] Version 0.8.5
12:21:51.342 utils.py DEBUG ['git', 'push', 'origin', '0.8.5-release']
12:21:51.905 github.py DEBUG Aucun PR ouvert trouvé
12:21:51.905 github.py DEBUG Tentative de PR pour la branche 0.8.5
12:21:53.215 github.py INFO PR créé :https://github.com/fedora-modularity/meta-test-family/pull/243
12:21:53.216 releasebot.py INFO Je viens de faire une demande de PR pour une version 0.8. 5
12:21:54.154 github.py DEBUG Commentaire ajouté au PR :Je viens de faire une demande de PR pour une version 0.8.5
Voici un [lien vers le PR](https://github .com/fedora-modularity/meta-test-family/pull/2 43)
12:21:54.154 github.py DEBUG Tentative de fermeture du problème n° 242
12:21:54.992 github.py DEBUG Problème fermé n° 242
Comme vous pouvez le voir, release-bot a automatiquement fermé le problème suivant, demandant une nouvelle version en amont de la meta-test-family :https://github.com/fedora-modularity/meta-test-family/issues/243.
De plus, release-bot a créé un nouveau PR avec changelog. Vous pouvez mettre à jour le PR (par exemple, le journal des modifications de squash) et une fois fusionné, il sera automatiquement publié sur GitHub, et PyPI et Fedora démarreront.
Vous disposez maintenant d'une solution fonctionnelle pour publier facilement des versions en amont de votre package dans PyPi et Fedora.
Modèle OpenShift
Une autre option pour fournir des versions automatisées à l'aide de release-bot consiste à le déployer dans OpenShift.
Le modèle OpenShift se présente comme suit :
kind :Template
apiVersion :v1
metadata :
name :release-bot
annotations :
description :S2I Relase-bot image builder
tags :release-bot s2i
iconClass :icon-python
labels :
template :release-bot
role :releasebot_application_builder
objects :
- kind :ImageStream
apiVersion :v1
metadata :
name :${APP_NAME}
labels :
appid :release-bot-${APP_NAME}
- kind :ImageStream
apiVersion :v1
metadata :
name :${APP_NAME}-s2i
labels :
appid :release-bot-${APP_NAME}
# scheduled :true
- kind :BuildConfig
apiVersion : v1
metadata :
name :${APP_NAME}
type :Git
git :
uri :${CONFIGURATION_REPOSITORY}
contextDir :${CONFIGURATION_REPOSITORY}
sourceSecret :
nom :release-bot -secret
strategy :
type :Source
sourceStrategy :
from :
kind :ImageStreamTag
name :${APP_NAME}-s2i:latest
sortie :
vers :
kind :ImageStreamTag
name :${APP_NAME}:latest
- kind :DeploymentConfig
apiVersion : v1
metadata :
nom :${APP_NAME}
labels :
appid :release-bot-${APP_NAME}
spec :
strategy :
type :Rolling
déclencheurs :
- type :ConfigC Hange
- Type:Imagecechange
ImagechangeParams:
Automatique:Vrai
Contenards:
- $ {Name}
Depuis:
Type:Imagestreamtag
nom :${APP_NAME}:latest
réplicas :1
sélecteur :
deploymentconfig :${APP_NAME}
modèle :
metadata :
image :${APP_NAME} :dernières
ressources :
requêtes :
mémoire : "64 Mi"
processeur : /> mémoire :"128Mi"
cpu :"100m"
paramètres :
- nom :APP_NAME
description :nom de l'ap plication
valeur :
requis :vrai
- nom :CONFIGURATION_REPOSITORY
description :référentiel Git avec configuration
valeur :
requis :vrai
Le moyen le plus simple de déployer le mtf-release-bot référentiel contenant des fichiers secrets dans OpenShift consiste à utiliser les deux commandes suivantes :
$ curl -sLO https://github.com/user-cont/release-bot/raw/master/openshift-template.yml Dans votre instance OpenShift, déployez le modèle en exécutant la commande suivante :
oc process -p APP_NAME="mtf-release-bot" -p CONFIGURATION_REPOSITORY="git@<git_lab_path>/mtf-release-conf.git" -f openshift-template.yml | oc apply Résumé
Consultez l'exemple de demande d'extraction dans le référentiel en amont de la famille de tests meta, où vous trouverez des informations sur ce que release-bot a publié. Une fois que vous arrivez à ce point, vous pouvez voir que release-bot est capable de pousser de nouvelles versions en amont dans GitHub, PyPI et Fedora sans intervention lourde de l'utilisateur. Il automatise toutes les étapes afin que vous n'ayez pas besoin de télécharger et de créer manuellement de nouvelles versions en amont de votre package.