{"meta":{"title":"Erstellen eines CI-Servers","intro":"Erstelle dein eigenes CI-System mithilfe der Status-API.","product":"REST-API","breadcrumbs":[{"href":"/de/rest","title":"REST-API"},{"href":"/de/rest/guides","title":"Anleitungen"},{"href":"/de/rest/guides/building-a-ci-server","title":"Erstellen eines CI-Servers"}],"documentType":"article"},"body":"# Erstellen eines CI-Servers\n\nErstelle dein eigenes CI-System mithilfe der Status-API.\n\nSie können die REST-API verwenden, um Commits mit einem Testdienst zu verknüpfen, sodass jeder von Ihnen vorgenommene Push in einer GitHub Pullanforderung getestet und dargestellt werden kann. Weitere Informationen zu den relevanten Endpunkten findest du unter [REST-API-Endpunkte für Commit-Status](/de/rest/commits/statuses).\n\nIn diesem Leitfaden wird diese API verwendet, um ein Setup zu veranschaulichen, das du verwenden kannst.\nIn unserem Szenario werden wir Folgendes tun:\n\n* Wir führen unsere CI-Suite aus, wenn ein Pull Request geöffnet wird (wir legen den CI-Status auf „Ausstehend“ fest).\n* Wenn die CI abgeschlossen ist, legen wir den Status des Pull Request entsprechend fest.\n\nUnser CI-System und der Hostserver sind Produkte unserer Vorstellungskraft. Es kann sich um Travis, Jenkins oder etwas völlig anderes handeln. Im Mittelpunkt dieses Leitfadens steht die Einrichtung und Konfiguration des Servers, der die Kommunikation verwaltet.\n\nWenn du den [Download von `ngrok`](https://ngrok.com/) noch nicht durchgeführt hast, solltest du dies tun und den [Umgang damit lernen](https://ngrok.com/docs/getting-started/). Dieses Tool ist sehr nützlich, um lokale Anwendungen im Internet zugänglich zu machen.\n\n> \\[!NOTE]\n> Alternativ kannst du die Webhookweiterleitung verwenden, um deine lokale Umgebung für den Empfang von Webhooks einzurichten. Weitere Informationen finden Sie unter [Verwenden der GitHub CLI zum Weiterleiten von Webhooks für Tests](/de/webhooks/testing-and-troubleshooting-webhooks/using-the-github-cli-to-forward-webhooks-for-testing).\n\nHinweis: Du kannst den vollständigen Quellcode für dieses Projekt [aus dem Repository mit den Plattformbeispielen](https://github.com/github/platform-samples/tree/master/api/ruby/building-a-ci-server) herunterladen.\n\n## Schreiben des Servers\n\nWir schreiben eine einfache Sinatra-App, um zu zeigen, dass unsere lokalen Verbindungen funktionieren.\nBeginnen wir hiermit:\n\n```ruby\nrequire 'sinatra'\nrequire 'json'\n\npost '/event_handler' do\n  payload = JSON.parse(params[:payload])\n  \"Well, it worked!\"\nend\n```\n\n(Wenn du nicht mit der Funktionsweise von Sinatra vertraut bist, solltest du den [Sinatra-Leitfaden](http://www.sinatrarb.com/) lesen.)\n\nStarte diesen Server. Sinatra wird standardmäßig auf Port `4567` gestartet. Daher solltest du `ngrok` so konfigurieren, dass es ebenfalls auf diesen Port lauscht.\n\nDamit dieser Server funktioniert, müssen wir ein Repository mit einem Webhook einrichten. Dieser Webhook sollte so konfiguriert werden, dass er ausgelöst wird, wenn ein Pull Request erstellt oder zusammengeführt wird.\n\nErstelle nun ein Repository, mit dem du experimentieren kannst. Dürfen wir Ihnen das von [@octocat vorgeschlagene Spoon/Knife-Repository](https://github.com/octocat/Spoon-Knife) präsentieren?\n\nDanach erstellst du einen neuen Webhook in deinem Repository, fügst die von `ngrok` bereitgestellte URL hinzu und wählst `application/x-www-form-urlencoded` als Inhaltstyp aus.\n\nKlicke auf **Webhook aktualisieren**. Der Antworttext `Well, it worked!` sollte angezeigt werden.\nSehr gut! Klicke auf **Individuelle Ereignisse auswählen**, und wähle Folgendes aus:\n\n* Status\n* Pullanforderung\n\nDies sind die Ereignisse GitHub , die an unseren Server gesendet werden, wenn die entsprechende Aktion auftritt. Aktualisieren wir unseren Server so, dass er im Moment *nur* das Pull Request-Szenario verarbeitet:\n\n```ruby\npost '/event_handler' do\n  @payload = JSON.parse(params[:payload])\n\n  case request.env['HTTP_X_GITHUB_EVENT']\n  when \"pull_request\"\n    if @payload[\"action\"] == \"opened\"\n      process_pull_request(@payload[\"pull_request\"])\n    end\n  end\nend\n\nhelpers do\n  def process_pull_request(pull_request)\n    puts \"It's #{pull_request['title']}\"\n  end\nend\n```\n\nWoran liegt das? Jedes von GitHub gesendete Ereignis enthält den HTTP-Header `X-GitHub-Event`. Wir kümmern uns jetzt nur um die PR-Veranstaltungen. Anschließend nehmen wir die Nutzdaten der Informationen und geben das Titelfeld zurück. Im Idealfall würde unser Server bei jeder Aktualisierung eines Pull Request reagieren, nicht nur, wenn er geöffnet wird. Dadurch wäre sichergestellt, dass jeder neue Push die CI-Tests übergibt.\nFür diese Demo konzentrieren wir uns jedoch nur darauf, wann sie geöffnet wird.\n\nNimm einige Änderungen in einem Branch deines Testrepositorys vor, öffne einen Pull Request, um diesen Proof of Concept zu testen. Dein Server sollte entsprechend reagieren.\n\n## Arbeiten mit Statusanzeigen\n\nDa unser Server nun eingerichtet ist, können wir mit unserer ersten Anforderung beginnen, nämlich dem Festlegen (und Aktualisieren) des CI-Status. Beachte, dass du bei jeder Aktualisierung des Servers auf **Redeliver** (Erneut übermitteln) klicken kannst, um die gleichen Nutzdaten zu senden. Du musst nicht für jede Änderung einen neuen Pull-Request erstellen.\n\nDa wir mit der GitHub API interagieren, verwenden wir [Octokit.rb](https://github.com/octokit/octokit.rb) , um unsere Interaktionen zu verwalten. Wir werden diesen Client mit [a personal access token](/de/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) konfigurieren:\n\n```ruby\n# !!! DO NOT EVER USE HARD-CODED VALUES IN A REAL APP !!!\n# Instead, set and test environment variables, like below\nACCESS_TOKEN = ENV['MY_PERSONAL_TOKEN']\n\nbefore do\n  @client ||= Octokit::Client.new(:access_token => ACCESS_TOKEN)\nend\n```\n\nDanach müssen wir die Pull-Anforderung GitHub nur aktualisieren, um klar zu machen, dass wir die Verarbeitung auf der CI durchführen:\n\n```ruby\ndef process_pull_request(pull_request)\n  puts \"Processing pull request...\"\n  @client.create_status(pull_request['base']['repo']['full_name'], pull_request['head']['sha'], 'pending')\nend\n```\n\nHier führen wir drei grundlegende Aktionen aus:\n\n* Wir suchen den vollständigen Namen des Repositorys.\n* Wir suchen den letzten SHA-Wert des Pull Requests.\n* Der Status wird auf „Ausstehend“ festgelegt.\n\nDas ist alles! Anschließend kannst du jeden Prozess ausführen, den du zum Ausführen deiner Testsammlung benötigst. Vielleicht übergibst du deinen Code an Jenkins oder rufen einen anderen Webdienst wie [Travis](https://api.travis-ci.com/docs/) über die API auf. Danach solltest du den Status erneut aktualisieren. In unserem Beispiel legen wir ihn einfach auf `\"success\"` fest:\n\n```ruby\ndef process_pull_request(pull_request)\n  @client.create_status(pull_request['base']['repo']['full_name'], pull_request['head']['sha'], 'pending')\n  sleep 2 # do busy work...\n  @client.create_status(pull_request['base']['repo']['full_name'], pull_request['head']['sha'], 'success')\n  puts \"Pull request processed!\"\nend\n```\n\n## Schlussbemerkung\n\nBei GitHub haben wir eine Version von [Janky](https://github.com/github/janky) verwendet, um unsere CI seit Jahren zu verwalten.\nDer grundlegende Ablauf ist im Wesentlichen derselbe wie bei dem Server, den wir oben erstellt haben.\nBei GitHub:\n\n* Wir tätigen eine Übermittlung an Jenkins, wenn ein Pull Request erstellt oder aktualisiert wird (über Janky).\n* Wir warten auf eine Antwort bezüglich des Status der CI.\n* Wenn der Code grün ist, müssen wir den Pull Request zusammenführen.\n\nDie gesamte Kommunikation wird zurück in unsere Chatrooms geleitet. Du musst kein eigenes CI-Setup einrichten, um dieses Beispiel zu verwenden.\nSie können sich jederzeit auf [GitHub Integrationen](https://github.com/integrations) verlassen."}