Upstream-Releases mit Release-Bot automatisieren

Wenn Sie ein GitHub-Repo besitzen oder verwalten und jemals ein Paket davon in PyPI und/oder Fedora gepusht haben, wissen Sie, dass es einige zusätzliche Arbeit unter Verwendung der Fedora-Infrastruktur erfordert.

Gute Nachrichten:Wir haben ein Tool namens Release-Bot entwickelt, das den Prozess automatisiert. Alles, was Sie tun müssen, ist, ein Problem in Ihrem Upstream-Repository einzureichen, und der Release-Bot kümmert sich um den Rest. Aber greifen wir uns nicht vor. Schauen wir uns zunächst an, was eingerichtet werden muss, damit diese Automatisierung stattfinden kann. Ich habe mich für die Meta-Test-Familie entschieden Upstream-Repository als Beispiel.

Konfigurationsdateien für Release-Bot

Es gibt zwei Konfigurationsdateien für release-bot:conf.yaml und release-conf.yaml .

conf.yaml

conf.yaml muss während der Bot-Initialisierung zugänglich sein; es gibt an, wie auf das GitHub-Repository zugegriffen wird. Um das zu zeigen, habe ich ein neues Git-Repository namens mtf-release-bot erstellt , die conf.yaml enthält und die anderen geheimen Dateien.

repository_name: name

repository_owner: owner

# https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/

github_token: xxxxxxxxxxxxxxxxxxxxxxxxx

# time in seconds during checks for new releases

refresh_interval: 180

Für den Fall der Meta-Testfamilie sieht die Konfigurationsdatei folgendermaßen aus:

repository_name: meta-test-family

repository_owner: fedora-modularity

github_token: xxxxxxxxxxxxxxxxxxxxx

refresh_interval: 180

release-conf.yaml

release-conf.yaml muss im Repository selbst gespeichert werden; es spezifiziert, wie GitHub/PyPI/Fedora-Releases durchgeführt werden.

# list of major python versions that bot will build separate wheels for

python_versions:

  - 2

  - 3

# optional:

changelog:

  - Example changelog entry

  - Another changelog entry

# this is info for the authorship of the changelog

# if this is not set, person who merged the release PR will be used as an author

author_name: John Doe

author_email: [email protected]

# whether to release on fedora. False by default

fedora: false

# list of fedora branches bot should release on. Master is always implied

fedora_branches:

  - f27

Für den Fall der Meta-Testfamilie sieht die Konfigurationsdatei folgendermaßen aus:

python_versions:

-       2

fedora: true

fedora_branches:

-       f29

-       f28

trigger_on_issue: true

PyPI-Konfigurationsdatei

Die Datei .pypirc , gespeichert in Ihrem mtf-release-bot privates Repository, wird zum Hochladen der neuen Paketversion in PyPI benötigt:

[pypi]

username = phracek

password = xxxxxxxx

Privater SSH-Schlüssel, id_rsa , die Sie in FAS konfiguriert haben.

Die endgültige Struktur des Git-Repositorys mit conf.yaml und die anderen sieht so aus:

$ ls -la

total 24

drwxrwxr-x   3 phracek phracek 4096 Sep 24 12:38 .

drwxrwxr-x. 20 phracek phracek 4096 Sep 24 12:37 ..

-rw-rw-r--   1 phracek phracek  199 Sep 24 12:26 conf.yaml

drwxrwxr-x   8 phracek phracek 4096 Sep 24 12:38 .git

-rw-rw-r--   1 phracek phracek 3243 Sep 24 12:38 id_rsa

-rw-------   1 phracek phracek   78 Sep 24 12:28 .pypirc

Anforderungen

Weitere Python-Ressourcen

• Was ist eine IDE?
• Spickzettel:Python 3.7 für Anfänger
• Top-Python-GUI-Frameworks
• Download:7 wichtige PyPI-Bibliotheken
• Red Hat-Entwickler
• Neueste Python-Inhalte

Für die Veröffentlichung auf PyPI ist das Wheel-Paket sowohl für Python 2 als auch für Python 3 erforderlich, also installieren Sie requirements.txt mit beiden Versionen von Pip. Außerdem müssen Sie Ihre PyPI-Anmeldedaten in $HOME/.pypirc einrichten , wie in der PyPI-Dokumentation beschrieben. Wenn Sie für Fedora freigeben, müssen Sie ein aktives Kerberos-Ticket haben, während der Bot läuft, oder den Pfad zur Kerberos-Keytab-Datei mit -k/–keytab angeben . Auch fedpkg erfordert, dass Sie einen SSH-Schlüssel in Ihrem Schlüsselbund haben, den Sie auf FAS hochgeladen haben.

So stellen Sie den Release-Bot bereit

Es gibt zwei Möglichkeiten, release-bot zu verwenden:als Docker-Image oder als OpenShift-Vorlage.

Docker-Image

Lassen Sie uns das Bild mit s2i erstellen Befehl:

$ s2i build $CONFIGURATION_REPOSITORY_URL usercont/release-bot app-name

wobei $CONFIGURATION_REPOSITORY_URL ist ein Verweis auf das GitHub-Repository, wie https:///mtf-release-conf.

Schauen wir uns Docker-Images an:

$ docker images

REPOSITORY                                      TAG                     IMAGE ID                CREATED                 SIZE

mtf-release-bot                         latest                  08897871e65e            6 minutes ago           705 MB

docker.io/usercont/release-bot                  latest                  5b34aa670639            9 days ago              705 MB

Versuchen wir nun, den mtf-release-bot auszuführen image mit diesem Befehl:

$ docker run mtf-release-bot

---> Setting up ssh key...

Agent pid 12

Identity added: ./.ssh/id_rsa (./.ssh/id_rsa)

12:21:18.982 configuration.py  DEBUG  Loaded configuration for fedora-modularity/meta-test-family

12:21:18.982 releasebot.py      INFO   release-bot v0.4.1 reporting for duty!

12:21:18.982 github.py          DEBUG  Fetching release-conf.yaml

12:21:37.611 releasebot.py      DEBUG  No merged release PR found

12:21:38.282 releasebot.py      INFO   Found new release issue with version: 0.8.5

12:21:42.565 releasebot.py      DEBUG  No more open issues found

12:21:43.190 releasebot.py      INFO   Making a new PR for release of version 0.8.5 based on an issue.

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/repos/branches/#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           ERROR  No version files found. Aborting version update.

12:21:48.014 utils.py           WARNING No CHANGELOG.md present in repository

[Errno 2] No such file or directory: '/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] 0.8.5 release



12:21:51.342 utils.py           DEBUG  ['git', 'push', 'origin', '0.8.5-release']



12:21:51.905 github.py          DEBUG  No open PR's found

12:21:51.905 github.py          DEBUG  Attempting a PR for 0.8.5-release branch

12:21:53.215 github.py          INFO   Created PR: https://github.com/fedora-modularity/meta-test-family/pull/243

12:21:53.216 releasebot.py      INFO   I just made a PR request for a release version 0.8.5

12:21:54.154 github.py          DEBUG  Comment added to PR: I just made a PR request for a release version 0.8.5

 Here's a [link to the PR](https://github.com/fedora-modularity/meta-test-family/pull/243)

12:21:54.154 github.py          DEBUG  Attempting to close issue #242

12:21:54.992 github.py          DEBUG  Closed issue #242

Wie Sie sehen können, hat der Release-Bot das folgende Problem automatisch geschlossen und eine neue Upstream-Version der Meta-Test-Familie angefordert:https://github.com/fedora-modularity/meta-test-family/issues/243.

Außerdem hat release-bot eine neue PR mit Changelog erstellt. Sie können die PR aktualisieren – zum Beispiel Squash Changelog – und sobald Sie sie zusammenführen, wird sie automatisch auf GitHub veröffentlicht und PyPI und Fedora werden gestartet.

Sie haben jetzt eine funktionierende Lösung, um problemlos Upstream-Versionen Ihres Pakets in PyPi und Fedora freizugeben.

OpenShift-Vorlage

Eine weitere Option zur Bereitstellung automatisierter Releases mit Release-Bot ist die Bereitstellung in OpenShift.

Die OpenShift-Vorlage sieht wie folgt aus:

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}

    spec :

      tags :

        - name : latest

          from :

            kind : DockerImage

            name : usercont/release-bot:latest

         #importPolicy:

         #  scheduled: true

  - kind : BuildConfig

    apiVersion : v1

    metadata :

      name : ${APP_NAME}

      labels :

        appid : release-bot-${APP_NAME}

    spec :

      triggers :

        - type : ConfigChange

        - type : ImageChange

      source :

        type : Git

        git :

          uri : ${CONFIGURATION_REPOSITORY}

          contextDir : ${CONFIGURATION_REPOSITORY}

        sourceSecret :

          name : release-bot-secret

      strategy :

        type : Source

        sourceStrategy :

          from :

            kind : ImageStreamTag

            name : ${APP_NAME}-s2i:latest

      output :

        to :

          kind : ImageStreamTag

          name : ${APP_NAME}:latest

  - kind : DeploymentConfig

    apiVersion : v1

    metadata :

      name: ${APP_NAME}

      labels :

        appid : release-bot-${APP_NAME}

    spec :

      strategy :

        type : Rolling

      triggers :

         - type : ConfigChange

         - type : ImageChange

           imageChangeParams :

             automatic : true

             containerNames :

               - ${APP_NAME}

             from :

               kind : ImageStreamTag

               name : ${APP_NAME}:latest

      replicas : 1

      selector :

        deploymentconfig : ${APP_NAME}

      template :

        metadata :

          labels :

            appid: release-bot-${APP_NAME}

            deploymentconfig : ${APP_NAME}

        spec :

          containers :

            - name : ${APP_NAME}

              image : ${APP_NAME}:latest

              resources:

                requests:

                  memory: "64Mi"

                  cpu: "50m"

                limits:

                  memory: "128Mi"

                  cpu: "100m"



parameters :

  - name : APP_NAME

    description : Name of application

    value :

    required : true

  - name : CONFIGURATION_REPOSITORY

    description : Git repository with configuration

    value :

    required : true

Der einfachste Weg, den mtf-release-bot bereitzustellen Repository mit geheimen Dateien in OpenShift verwenden Sie die folgenden zwei Befehle:

$ curl -sLO https://github.com/user-cont/release-bot/raw/master/openshift-template.yml

Stellen Sie in Ihrer OpenShift-Instanz die Vorlage bereit, indem Sie den folgenden Befehl ausführen:

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

Zusammenfassung

Sehen Sie sich den Beispiel-Pull-Request im Upstream-Repository meta-test-family an, wo Sie Informationen darüber finden, welcher Release-Bot veröffentlicht wurde. Sobald Sie an diesem Punkt angelangt sind, können Sie sehen, dass der Release-Bot in der Lage ist, neue Upstream-Versionen ohne großen Benutzereingriff in GitHub, PyPI und Fedora zu pushen. Es automatisiert alle Schritte, sodass Sie keine neuen Upstream-Versionen Ihres Pakets manuell hochladen und erstellen müssen.