Exemple d'implémentation d'intégration continue à l'aide de BuildBot

(Image par Computerizer de Pixabay)

Salut

Je m'appelle Evgeny Cherkin , je suis le programmeur de l'équipe de développement de la société minière Polymetal .

Lorsque vous lancez un projet majeur, vous commencez à penser: "Quel logiciel est préférable d'utiliser pour sa maintenance?". Un projet informatique avant la sortie de la prochaine version passe par une série d'étapes. C'est bien quand la chaîne de ces étapes est automatisée. Le processus automatisé de publication d'une nouvelle version d'un projet informatique est appelé intégration continue . BuildBot s'est avéré être une bonne aide pour nous, implémentant ce processus.

Dans cet article, j'ai décidé de fournir un aperçu des fonctionnalités de BuildBot . De quoi est capable ce logiciel? Comment l'approcher et comment construire avec lui une RELATION DE TRAVAIL EFFICACE normale? Vous pouvez également vous appliquer notre expérience en créant sur votre machine un service de travail pour assembler et tester votre projet.

1. Pourquoi BuildBot?

---

Plus tôt sur habr-e, je suis tombé sur des articles sur la mise en œuvre de l' intégration continue à l' aide de BuildBot . Par exemple, celui-ci m'a semblé le plus instructif. Il y a un autre exemple - plus simple . Ces articles peuvent être assaisonnés avec un exemple tiré du manuel , et ce après, en anglais. Le coupé est un bon point de départ. Après avoir lu ces articles, vous voudrez probablement faire quelque chose sur BuildBot tout de suite .

Arrête ça! Quelqu'un l'a-t-il même utilisé dans ses projets? Il s'avère que oui, beaucoup l'ont appliqué dans leurs tâches. Vous pouvez trouver des exemples d' utilisation de BuildBot dans les archives de code Google.

Alors, quelle est la logique des gens qui utilisent buildbot ? Après tout, il existe d'autres outils: CruiseControl et Jenkins . Je répondrai de cette façon. Pour la plupart des tâches, Jenkins sera vraiment suffisant. BuildBot , à son tour, est plus adaptatif, et les tâches y sont résolues aussi facilement que dans Jenkins . Choisissez-vous. Mais comme nous recherchons un outil pour un projet cible en développement, pourquoi ne pas choisir celui qui nous permet, à partir d'étapes simples, d'obtenir un système de build interactif et doté d'une interface unique.

Pour ceux dont le projet cible est écrit en python, la question se pose: «Pourquoi ne pas choisir un système d'intégration qui a une interface claire en termes de langage utilisé dans le projet?». Et puis il est temps de présenter les avantages de BuildBot .

Alors, notre «quatuor instrumental». Pour moi, j'ai défini les quatre fonctionnalités de BuildBot :

1. Ceci est un framework open source sous la GPL
2. Cela utilise python comme outil de configuration et décrit les actions requises.
3. C'est l'occasion de recevoir une réponse de la machine sur laquelle se déroule le montage.
4. Ce sont enfin les exigences minimales pour l'hôte. Le déploiement nécessite python et twisted, et aucune machine virtuelle ou machine java n'est requise.

2. Concept dirigé par BuildMaster

---

BuildMaster est au cœur de l' architecture de distribution des tâches . C'est un service qui:

• suit les changements dans l'arborescence source du projet
• envoie les commandes que le service Worker doit exécuter pour créer un projet et le tester
• informe les utilisateurs des résultats des actions entreprises

BuildMaster est configuré via le fichier master.cfg . Ce fichier est à la racine de BuildMaster . Plus tard, je montrerai comment cette racine est créée. Le fichier master.cfg lui - même contient python, un script qui utilise les appels BuildBot .

Le prochain BuildBot le plus important est appelé Worker . Ce service peut être exécuté sur un hôte différent avec un système d'exploitation différent, ou peut-être sur l'emplacement de BuildMaster . Il peut également exister dans un environnement virtuel spécialement préparé avec ses propres packages et variables. Ces environnements virtuels peuvent être préparés à l'aide d'utilitaires python comme vertualenv, venv .

BuildMaster diffuse des commandes à chaque Worker , qui, à son tour, les exécute. Autrement dit, il s'avère que le processus de construction et de test du projet peut aller au Worker sous Windows et à un autre Worker sous Linux.

La récupération du code source du projet se produit sur chaque Worker .

3. Installation

---

Alors allons-y. J'utiliserai Ubuntu 18.04 comme hôte. Je vais y placer un BuildMaster -a et un Worker -a. Mais vous devez d'abord installer python3.7:

sudo apt-get update sudo apt-get install python3.7 

Pour ceux qui ont besoin de python3.7.2 au lieu de 3.7.1, vous pouvez faire ce qui suit:

 sudo apt-get update sudo apt-get software-properties-common sudo add-apt-repository ppa:deadsnakes/ppa sudo apt-get install python3.7 sudo ln -fs /usr/bin/python3.7 /usr/bin/python3 pip3 install --upgrade pip 

L'étape suivante consiste à installer Twited et BuildBot , ainsi que des packages qui activent des fonctionnalités BuildBot -a supplémentaires.

 /*   sudo        /usr/local/lib/python3.7/dist-packages*/ #     Worker- sudo pip install twisted # twisted sudo pip install buildbot #BuildMaster #  pip install pysqlite3 #  sqllite    pip install jinja2 #framework  django,  web     pip install autobahn #Web c   BuildMaster->Worker pip install sqlalchemy sqlalchemy-migrate #     # Web  BuildBot-a pip install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view pip install python-dateutil #   web #         pip install buildbot-worker #Worker #  sudo pip install virtualenv #  

4. Premières étapes

---

Il est temps de créer un BuildMaster . Nous l'aurons dans le dossier / home / habr / master .

 mkdir master buildbot create-master master #     

La prochaine étape. Créez un travailleur . Nous l'aurons dans le dossier / home / habr / worker .

 mkdir worker buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password 

Lorsque vous démarrez Worker , par défaut, il crée un dossier dans / home / habr / worker avec le nom du projet, qui est spécifié dans master.cfg . Et dans le dossier avec le nom du projet, il créera le répertoire de construction , puis la vérification y sera effectuée. Le répertoire de travail de Worker sera le répertoire / home / habr / yourProject / build .

Clé d'or
Et maintenant, pour ce que j'ai écrit le paragraphe précédent: le script que Master exigera que Worker fasse à distance dans ce répertoire ne sera pas exécuté, car le script n'a pas la permission de s'exécuter. Pour corriger la situation, vous avez besoin d'une clé --umask = 0o22 , ce qui interdit d'écrire dans ce répertoire, mais laisse les droits de démarrage. Et nous en avons seulement besoin.

BuildMaster et Worker établissent une connexion entre eux. Il arrive qu'il se casse et Worker attend une réponse de BuildMaster pendant un certain temps. Si aucune réponse n'est reçue, la connexion est redémarrée. La clé --keepalive = 60 est exactement ce dont vous avez besoin pour indiquer le temps après lequel la connexion redémarre.

5. Configuration. Recette étape par étape

---

La configuration de BuildMaster se fait côté machine, où nous avons exécuté la commande create-master . Dans notre cas, il s'agit du répertoire / home / habr / master . Le fichier de configuration master.cfg n'existe pas encore, mais la commande elle-même a déjà créé le fichier master.cmg.sample . Vous devez le renommer dans master.cfg.sample en master.cfg

 mv master.cfg.sample master.cfg 

Ouvrons ce master.cfg . Et nous analyserons en quoi il consiste. Et après cela, nous essaierons de créer notre propre fichier de configuration.

5.1 BuildmasterConfig

 c = BuildmasterConfig = {} 

BuildmasterConfig - le dictionnaire de base du fichier de configuration. Il doit être impliqué dans le fichier de configuration. Pour plus de facilité d'utilisation, son alias "c" est saisi dans le code de configuration. Les noms de clés dans c ["keyFromDist"] sont des éléments fixes pour interagir avec BuildMaster . Sous chaque clé, l'objet correspondant est substitué en tant que valeur.

5.2 travailleurs

 c['workers'] = [worker.Worker("example-worker", "pass")] 

Cette fois, nous signalons la liste BuildMaster des travailleurs . Nous avons créé Worker ci-dessus en spécifiant votre nom de travailleur et votre mot de passe . Maintenant, ils doivent être spécifiés au lieu d' exemple-travailleur et passer .

5.3 change_source

 c['change_source'] = [] c['change_source'].append(changes.GitPoller( 'git://github.com/buildbot/hello-world.git', workdir='gitpoller-workdir', branch='master', pollInterval=300)) 

En utilisant la clé change_source du dictionnaire c , nous avons accès à la liste où vous souhaitez placer l'objet qui interroge le référentiel avec le code source du projet. L'exemple utilise le référentiel Git, qui est interrogé à une certaine périodicité.

Le premier argument est le chemin d'accès à votre référentiel.

workdir est le chemin d'accès au dossier où, du côté du travailleur , par rapport au chemin / home / habr / worker / yourProject / build, git stockera la version locale du référentiel.

branche contient une branche spécifique dans le référentiel qui doit être surveillée.

pollInterval contient le nombre de secondes après lesquelles BuildMaster interrogera le référentiel pour les modifications.

Il existe plusieurs méthodes pour suivre les modifications dans un référentiel de projet.

La méthode la plus simple est Polling , ce qui implique que BuildMaster interroge périodiquement le serveur avec le référentiel. Si commit reflétait les changements dans le référentiel, alors BuildMaster créera un certain délai un objet Change interne et l'enverra au gestionnaire d'événements du planificateur , qui lancera les étapes de génération et de test du projet sur Worker . Parmi ces étapes, la mise à jour du référentiel sera indiquée. C'est sur Worker qu'une copie locale du référentiel sera créée. Les détails de ce processus seront divulgués ci-dessous dans les deux sections suivantes ( 5.4 et 5.5 ) .

Une méthode encore plus élégante de suivi des modifications dans le référentiel consiste à envoyer des messages directement depuis le serveur sur lequel il se trouve à BuildMaster concernant la modification des codes source du projet. Dans ce cas, dès que le développeur effectue une validation , le serveur avec le référentiel de projet enverra un message à BuildMaster . Et cela, à son tour, sera intercepté en créant un objet PBChangeSource . De plus, cet objet sera transféré à Scheduler , qui activera les étapes de construction du projet et ses tests. Une partie importante de cette méthode consiste à travailler avec des scripts de hook de serveur dans le référentiel. Dans le script de raccordement responsable de la gestion des actions lors de la validation , vous devez appeler l'utilitaire sendchange et spécifier l'adresse réseau de BuildMaster . Vous devez spécifier le port réseau qui écoutera PBChangeSource . Soit dit en passant, PBChangeSource fait partie de BuildMaster . Cette méthode nécessite le privilège admin -a sur le serveur où se trouve le référentiel de projet. Vous devez d'abord créer un référentiel de sauvegarde.

5.4 déchiqueteurs

 c['schedulers'] = [] c['schedulers'].append(schedulers.SingleBranchScheduler( name="all", change_filter=util.ChangeFilter(branch='master'), treeStableTimer=None, builderNames=["runtests"])) c['schedulers'].append(schedulers.ForceScheduler( name="force", builderNames=["runtests"])) 

Les ordonnanceurs sont un élément qui agit comme un déclencheur qui exécute l'ensemble de la chaîne d'assemblage et de test d'un projet.


Ces modifications qui ont été enregistrées par change_source ont été converties pendant le fonctionnement de BuildBot -a en l'objet Change et maintenant chaque Sheduler en fonction d'eux crée des demandes pour démarrer le processus de génération de projet. Cependant, il détermine également quand envoyer ces demandes à la file d'attente. Objet Le générateur conserve une file d'attente de demandes et surveille le statut de l'assembly actuel sur un Worker -e distinct. Le générateur existe sur BuildMaster -e et Worker -e. Il envoie une build spécifique de BuildMaster à Worker , une série d'étapes qui doivent être suivies.
Nous voyons que dans l'exemple actuel de tels ordonnanceurs , 2 pièces sont créées. De plus, chacun a son propre type.

SingleBranchScheduler est l'une des classes d'horaires les plus populaires. Il surveille une branche et est déclenché par un changement enregistré dans celle-ci. Lorsqu'il voit les modifications, il peut reporter l'envoi d'une demande de construction (reporter pour la période spécifiée dans le paramètre spécial treeStableTimer ). Le nom spécifie le nom de la planification qui sera affichée dans l'interface BuildBot -web. Un filtre est défini dans ChangeFilter , après avoir traversé les modifications de la branche qui invitent la planification à envoyer une demande de génération. Le nom builder -a est spécifié dans builderNames , que nous préciserons un peu plus tard. Le nom dans notre cas sera le même que le nom du projet: yourProject .

ForceScheduler est une chose très simple. Ce type de planification est déclenché par un clic de souris via l'interface BuildBot -web. Les paramètres ont la même essence que dans SingleBranchScheduler .

PS n ° 3. Soudainement utile
Périodique est un programme qui est déclenché à une fréquence fixe dans le temps. Cela ressemble à un appel comme celui-ci

 from buildbot.plugins import schedulers nightly = schedulers.Periodic(name="daily", builderNames=["full-solaris"], periodicBuildTimer=24*60*60) c['schedulers'] = [nightly] 

5.5 BuildFactory

 factory = util.BuildFactory() factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental')) factory.addStep(steps.ShellCommand(command=["trial", "hello"], env={"PYTHONPATH": "."})) 

periodicalBuildTimer définit le temps de cette périodicité en secondes.

BuildFactory crée une construction en béton, que le générateur envoie ensuite au Worker . BuildFactory indique les étapes qu'un Worker doit suivre. Les étapes sont ajoutées en appelant la méthode addStep.


La première étape ajoutée dans cet exemple est git clean -d -f -f –x , puis git checkout . Ces actions sont intégrées dans le paramètre de méthode , qui n'est pas clairement indiqué, mais implique la valeur par défaut de fresh . Le paramètre mode = 'incremental' indique que les fichiers du répertoire où s'effectue le chechout, bien qu'ils soient absents du référentiel, restent intacts.

La deuxième étape ajoutée consiste à appeler le script d' essai avec le paramètre hello du côté Worker depuis le répertoire / home / habr / worker / yourProject / build avec la variable d'environnement PATHONPATH = ... Vous pouvez donc écrire vos propres scripts et les exécuter du côté Worker -a via l'étape util.ShellCommand . Ces scripts peuvent être placés directement dans le référentiel. Ensuite, pendant le chechout, ils iront dans / home / habr / worker / yourProject / build . Cependant, il y a ensuite deux «mais»:

1. Le travailleur doit être créé avec le commutateur --umask afin qu'il ne bloque pas les droits d'exécution après l' extraction -a.
2. Lorsque git envoie ces scripts, il est nécessaire de spécifier la propriété exacutable , afin qu'avec chechout -e Git ne perde pas le droit d'exécuter le script.

5.6 constructeurs

 c['builders'] = [] c['builders'].append(util.BuilderConfig(name="runtests", workernames=["example-worker"], factory=factory)) 

À propos de ce que Builder a été décrit ici . Je vais maintenant parler plus en détail de la façon de le créer. BuilderConfig est un constructeur constructeur . Vous pouvez spécifier plusieurs de ces constructeurs dans c ['constructeurs'] , car il s'agit d'une liste d'objets de type constructeur . Nous allons maintenant réécrire légèrement l'exemple de BuildBot , en le rapprochant de notre tâche.

 c['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory)) 

Je vais maintenant parler des paramètres BuilderConfig .

nom définit le constructeur de noms -a. Ici, nous l'avons appelé votre projet . Cela signifie que sur le Worker, ce chemin / home / habr / worker / yourProject / build sera créé. Sheduler recherche un constructeur par ce nom.

workernames contient une liste de Workers . Dont chacun doit être ajouté à c [«travailleurs»] .

factory est le build spécifique auquel le constructeur est associé. Il enverra un objet de génération à Worker pour terminer toutes les étapes qui composent cette génération -a.

6. Exemple de configuration propre

---

Voici l'architecture d'un exemple de projet que je propose de mettre en œuvre via BuildBot
.

Nous utiliserons svn comme système de contrôle de version. Le référentiel lui-même sera dans un certain cloud. Voici l'adresse de ce cloud svn.host/svn/yourProject/trunk . Dans le cloud sous svn, il y a un nom d'utilisateur: utilisateur , passwd: mot de passe . Les scripts qui constituent les étapes de build -a se trouvent également dans la branche svn , dans un dossier buildbot / worker_linux distinct . Ces scripts sont dans le référentiel avec la propriété exécutable enregistrée.

BuildMaster et Worker fonctionnent sur le même hôte project.host . BuildMaster stocke ses fichiers dans le dossier / home / habr / master . Worker stocke le chemin suivant / home / habr / worker . La communication entre les processus BuildMaster et Worker s'effectue via le port 4000 à l'aide du protocole BuildBot -a, c'est-à-dire le protocole «pb» .

Le projet cible est entièrement écrit en python. La tâche consiste à suivre ses modifications, à créer un fichier exécutable, à générer de la documentation et à effectuer des tests. En cas d'échec, tous les développeurs doivent envoyer un message au courrier électronique indiquant qu'une action a échoué.

Nous allons connecter la cartographie Web BuildBot au port 80 pour project.host . Apatch est facultatif. La bibliothèque torsadée possède déjà un serveur Web, BuildBot l' utilise.

Nous utiliserons sqlite pour stocker des informations internes pour BuildBot .

Pour l'envoi, vous avez besoin de l'hôte smtp.your.domain - il permet d'envoyer des e-mails depuis projectHost@your.domain sans authentification. Également sur l'hôte « smtp », le protocole est écouté à 1025.

Il y a deux personnes impliquées dans le processus: l' administrateur et l' utilisateur . admin administre BuildBot . utilisateur est la personne qui commet la validation .

Un fichier exacutable est généré via pyinstaller . La documentation est générée via doxygen .

Pour cette architecture, j'ai écrit ce master.cfg :


Vous devez d'abord créer BuildMaster et Worker -a. Collez ensuite ce fichier master.cfg dans / home / habr / master .

L'étape suivante consiste à démarrer le service BuildMaster

 sudo buildbot start /home/habr/master 

Ensuite, démarrez le service Worker -a

 buildbot-worker start /home/habr/worker 

C'est fait! Maintenant, Buildbot suivra les modifications et s'exécutera lors de la validation dans svn , en suivant les étapes de construction et de test du projet avec l'architecture ci-dessus.

Ci-dessous, je décrirai quelques fonctionnalités du master.cfg ci-dessus .

6.1 En route vers votre master.cfg

Lors de l'écriture de votre master.cfg, de nombreuses erreurs seront commises, vous devrez donc lire le fichier journal. Il est stocké à la fois sur le chemin absolu BuildMaster -ec /home/habr/master/twistd.log et sur le côté Worker -a avec le chemin absolu /home/habr/worker/twistd.log . Lorsque vous lisez l'erreur et la corrigez , vous devrez redémarrer le service BuildMaster -a. Voici comment procéder:

 sudo buildbot stop /home/habr/master sudo buildbot upgrade-master /home/habr/master sudo buildbot start /home/habr/master 

6.2 Travailler avec svn

 svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk", svnuser="user", svnpasswd="password", pollinterval=60, split_file=util.svn.split_file_alwaystrunk ) c['change_source'] = svn_poller hourlyscheduler = schedulers.SingleBranchScheduler( name="your-project-schedulers", change_filter=util.ChangeFilter(branch=None), builderNames=["yourProject"], properties = {'owner': 'admin'} ) c['schedulers'] = [hourlyscheduler] checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk', mode='full', method='fresh', username="user", password="password", haltOnFailure=True) 

Tout d'abord, jetez un œil à svn_poller . Il s'agit de la même interface qui interroge régulièrement le référentiel une fois par minute. Dans ce cas, svn_poller accède uniquement à la branche du tronc . Le mystérieux paramètre split_file = util.svn.split_file_alwaystrunk définit les règles: comment diviser la structure des dossiers svn en branches. Il leur propose des moyens relatifs. À son tour, split_file_alwaystrunk simplifie le processus en disant que seul le tronc est dans le référentiel.

Dans Schedulers , ChangeFilter est spécifié , qui voit None et associe la branche de jonction avec elle en fonction de l'association spécifiée via split_file_alwaystrunk . Répondant aux modifications du tronc , il démarre le générateur nommé yourProject .

Les propriétés ici sont nécessaires pour que l'administrateur reçoive la newsletter de l'assembly et teste les résultats en tant que propriétaire du processus.

L'étape de vérification de build -a est capable de supprimer complètement tous les fichiers qui se trouvent dans la version locale du référentiel Worker . Faites ensuite la mise à jour svn complète. Le mode est configuré via le paramètre mode = full , method = fresh . Le paramètre haltOnTailure indique que si la mise à jour svn échoue , l'ensemble du processus d'assemblage et de test doit être suspendu, car les étapes ultérieures n'ont aucun sens.

6.3 Une lettre à vous: les journalistes sont autorisés à déclarer

reporters est un service de notification par courrier.

 template_html=u'''\ <h4>  : {{ summary }}</h4> <p>   : {{ workername }}</p> <p>: {{ projects }}</p> <p>         : {{ buildbot_url }}</p> <p>         : {{ build_url }}</p> <p> WinSCP     c ip:xxx.xx.xxx.xx.   habr/password,   executable    ~/worker/yourProject/build/dist.</p> <p><b>    Buildbot</b></p> ''' sendMessageToAll = reporters.MailNotifier(fromaddr="projectHost@your.domain", sendToInterestedUsers=True, lookup="your.domain", relayhost="smtp.your.domain", smtpPort=1025, mode="warnings", extraRecipients=['user@your.domain'], messageFormatter=reporters.MessageFormatter( template=template_html, template_type='html', wantProperties=True, wantSteps=True) ) c['services'] = [sendMessageToAll] 

Il peut envoyer des messages de plusieurs manières .

MailNotifier utilise le courrier électronique pour envoyer des notifications.

template_html définit le modèle de texte pour la newsletter. Pour créer un balisage, utilisez html. Il est modifié par le moteur jinja2 (peut être comparé à django ). BuildBot a un ensemble de variables, dont les valeurs sont substituées dans le modèle dans le processus de formation du texte du message. Ces variables sont inscrites entre {{accolades doubles}}. Ainsi, par exemple, le résumé affiche l'état des opérations terminées, c'est-à-dire le succès ou l'échec. Et les projets généreront votre projet . Ainsi, en utilisant les commandes de contrôle dans jinja2 , les variables BuildBot et les formateurs de chaînes python, vous pouvez créer un message très informatif.

MailNotifier contient les arguments suivants.

fromaddr - l'adresse à partir de laquelle tout le monde recevra la newsletter.

sendToInterestedUsers = True envoie un message au propriétaire et à l'utilisateur qui ont effectué la validation .

recherche - suffixe à ajouter aux noms des utilisateurs recevant la newsletter. L' administrateur en tant qu'utilisateur recevra donc la newsletter à admin@your.domain.

relayhost spécifie le nom d'hôte sur lequel le serveur smtp est ouvert et smptPort spécifie le numéro de port sur lequel le serveur smtp écoute.

mode = «warning» indique que l'envoi ne doit être effectué que s'il y a au moins une étape de génération qui s'est terminée avec un état d'échec ou d'avertissement. En cas de succès, l'envoi n'est pas obligatoire.

extraRecipients contient une liste de personnes à qui le mailing doit être fait en plus du propriétaire et de la personne qui a effectué la validation .

messageFormatter est un objet qui définit le format du message, son modèle et l'ensemble de variables disponibles à partir de jinja2 . Des paramètres tels que wantProperties = True et wantSteps = True spécifient cet ensemble de variables disponibles.

with ['services'] = [sendMessageToAll] fournit une liste de services, parmi lesquels nosjournaliste .

Nous l'avons fait! Mes félicitations

---

Nous avons créé notre propre configuration et vu les fonctionnalités dont BuildBot est capable . Je pense que cela suffit pour comprendre si cet outil est nécessaire pour créer votre projet. Est-ce qu'il vous intéresse? Cela vous sera-t-il utile? Est-il pratique de travailler avec? Ensuite, j'écris cet article pour une bonne raison.

Et encore une chose.J'aimerais que la communauté professionnelle utilisant BuildBot devienne plus large, des manuels traduits et plus d'exemples.

Merci à tous pour votre attention. Bonne chance