Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Niko Wenselowski Newsgroups: de.comp.lang.python Subject: Re: [Python-de] Komplexe Jenkins Konfiguration - will man das? Date: Wed, 4 May 2016 08:34:32 +0200 Lines: 65 Message-ID: References: <57285B9B.8010308@thomas-guettler.de> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: news.uni-berlin.de +CmOwN40Dd/PAT3nLkjqgAoQcKPOQ+evXWZDroteTidQ== Return-Path: X-Original-To: python-de@python.org Delivered-To: python-de@mail.python.org In-Reply-To: <57285B9B.8010308@thomas-guettler.de> X-Mailer: Apple Mail (2.3124) X-BeenThere: python-de@python.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Die Deutsche Python Mailingliste List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <57285B9B.8010308@thomas-guettler.de> Xref: csiph.com de.comp.lang.python:4443 Hallo zusammen, > Am 03.05.2016 um 10:04 schrieb Thomas G=C3=BCttler = : > Ich habe gelesen, dass Jenkins2 Pipelines unterst=C3=BCtzt. Siehe = https://jenkins.io/doc/pipeline/ >=20 > Ich frage mich gerade: Will man das? Ich habe dieses Feature mit Neugierde aufgenommen und finde es spannend, = aber gleichzeitig die M=C3=B6glichkeiten aktuell noch einigerma=C3=9Fen = limitiert. Ich sehe aktuell keinen wichtigen Grund vorhandene Jobs auf Pipelines = umzubauen. Mir fehlt besonders die M=C3=B6glichkeit = Multikonfigurationsprojekte abzubilden, um so gegen verschiedene = Python-Versionen zu testen. Aktuell nutze ich daf=C3=BCr das Plugin von = ShiningPanda. Eine M=C3=B6glichkeit ist hier vermutlich einen bereits existierendes = Multikonfigurationssprojekt aufzurufen. Die M=C3=B6glichkeit vorhandene Projekte einzubinden ist in meinen Augen = eine der St=C3=A4rken der Pipeline. Dadurch muss nicht alles neu = geschrieben werden, auf bew=C3=A4hrtes kann ich zur=C3=BCckgreifen. Was ich als eine sehr gro=C3=9Fe St=C3=A4rke der Pipelines empfinde ist = die Darstellung. Ich habe einen lang laufenden Job, der Dokumentation in = verschiedenen Sprachen und Formaten erstellt, testweise mit Pipelines = umgesetzt. Wer auf die Dokumentation wartet, kann sofort sehen an welcher Stelle = gerade der Job besch=C3=A4ftigt ist - oder eventuell abgebrochen ist - = und wie lange er vermutlich noch bis zum Ende ben=C3=B6tigt. Jenkins hatte vorher bereits eine Ansicht der Builddauer unter = =E2=80=9ETrends=E2=80=9C, aber dort sah man weder einzelne Schritte, = noch die Gesamtdauer, wenn ich einen Jobverbund hatte. Interessant finde ich auch, dass man vorhandene Builds wiederholen kann. = Ist mir das vorher nur nie aufgefallen oder existierte diese = M=C3=B6glichkeit im Kern wirklich nicht? > Bisher versuchen wir die Konfig in Jenkins m=C3=B6glichst = unkompliziert zu machen. >=20 > Jenkins ruft ein Script auf, und zeigt ggf das Ergebnis der Tests. Ich denke das ist eine gute Idee. Verschiedene Schritte existieren bei = uns als Scripte, so dass jeder Entwickler einfach die Tests laufen = lassen oder Pakete f=C3=BCr Deployments erstellen kann. Eine weitere Limitierung der Pipelines ist =C3=BCbrigens, dass man keine = Test-Ergebnisse und Coverage darstellen lassen kann. Das ist f=C3=BCr = mich bisher der Grund gewesen bei Jenkins zu bleiben und nicht zu Gitlab = CI oder =C3=A4hnlichem zu wechseln. > Bin ich nun zu alt oder zu ignorant wenn ich mir sage: "Mich = interessieren diese Pipelines > =C3=BCberhaupt nicht=E2=80=9C? Nein, ich denke hier h=C3=A4ngt es stark vom Anwendungsfall ab. Wie Arnold geschrieben hat nutzt ihr im Prinzip schon Pipelines - = nur eben nicht mit den Mitteln von Jenkins. Gru=C3=9F Niko