So, es geht weiter mit demnächstenThorsten.
Und der erzählt uns was über GitHubActions Workflows.
Viel Spaß.
Genau.
Ja, guten Morgen.
Herzlich willkommen.
Wir schauen uns GitHub Actions an.
GitHub Actions Workflows und alles,was dazu gehört.
Mal schauen, ob das funktioniert.
Ja, genau.
GitHub Actions.
Erstmal, was sind GitHub Actions oder wasist GitHub Actions?
Im Prinzip ist es ein CI-CD-System.
Das kennen wir zum Beispiel fürverschiedenste Dinge, die man machen
möchte, nachdem man einen Code geschriebenhat und den irgendwo online schiebt.
Travis CI, Circle CI oder irgendwelcheTools und Services wie Jenkins zum Beispiel.
Und GitHub Actions ist eine weiterePlattform.
Was kann man damit machen?
Ja, es ist die Automatisierung vonverschiedensten Dingen, die man machen
möchte, nachdem man einen Code geschriebenhat.
Oder auch einfach so andere Trigger.
Da werden wir zu kommen.
Und naja, das Tolle isthalt, dass GitHub Actions...
Schauen wir mal, ob daswährenddessen funktioniert.
Das Tolle ist, dassGitHub Actions direkt in
GitHub als Plattformfest und tief integriert ist.
Schauen.
Super.
Das heißt, das erlaubt uns einmal,GitHub als Plattform, als Website,
die wir halt nutzen und kennen,einfach weiterzuverwenden.
Und auch erlaubt das, dass wir nicht nurauf Events wie...
Ich habe Code gepusht,reagieren können und irgendwelche
Automatisten oderAutomatisierungen anstoßen können.
Sondern fast alles, was GitHub als Service-Plattform anbietet.
Zum Beispiel, es wurde ein Issue erstellt.
Es wurde ein Pull-Request mit einem Labelversehen.
Oder sämtliche andere Dinge können einTrigger sein für irgendeine Automatisierung.
Warum sollte man GitHub Actions nutzen?
Das ist jetzt nichtganz speziell für GitHub
Actions, sondern ebenfür ein CI-CD -System.
Man kann eben bauen von Applikationen ausseinen Quelldateien.
Oder Tests oder eben den Code Deployenautomatisieren.
Im Prinzip ist es möglich, dass man völligeigenständige Arbeitsabläufe erstellt.
Durch eigenen Code oderwiederverwendbare Bausteine, die man
einfach benutzen kann und inseinen Ablauf einbinden kann.
Wie gesagt, es ist in GitHub integriert.
Es ist kein Setup nötig.
Man lädt eine Konfigurationsdatei hoch.
Das ist auch gleichzeitig schon dieBeschreibung meines Arbeitsablaufs.
Und das war's.
Und es gibt eine riesige Community vonkostenfreien Actions.
Das sind eben Bausteine, die ich verwendenkann.
Oder Workflows.
Das sind Arbeitsabläufe, die Actionsbenutzen können.
Dazu kommen wir gleich.
Also wie kann ich sie benutzen?
Im Prinzip geht es beim GitHub ActionsSystem um mehrere Begrifflichkeiten.
Wir haben halt einmal einen Workflow.
Das ist dieser Arbeitsablauf, derangestoßen wird.
Das ist die gesamte weiße Box.
Angestoßen wird dieserArbeitsablauf von einem
von mehreren möglichenTriggern oder Events.
Dann kann es sein, dass wir mehrere Jobshaben, die laufen auf einer
Docker-Umgebung, auf einer virtuellen Maschine irgendwo.
Und so ein Job kann verschiedene Schrittein einer sequentiellen Abfolge ausführen.
Das heißt, so ist zum Beispiel eineBeispiel-Workflow-Datei.
Wir haben hier einmal oben den Trigger.
Wenn Code gepusht wird, möchte ich,dass dieser Ablauf gestartet wird.
Dann haben wir einen Job definiert,der heißt GitHub Actions Demo.
Das ist willkürlich einfach gewählt.
Dieser Job hat mehrere Steps.
Und der erste ist, ich führe ein bisschenCode aus.
Dann benutze ich eineAction, ein fest irgendwo
angebotenes Arbeitspaketvon verschiedenen Sachen.
Das können auch wieder mehrere Schrittesein.
Und dann führe ich nochmal ein bisschenCode aus.
Wofür kann man die benutzen?
Für zum Beispiel statische Analysen vonCode.
Coding-Standards oder irgendwelchestatischen Analysen wie Psalm oder sonstige
Fehlerüberprüfungen.
Ich kann irgendwelche Quelldateien wie zumBeispiel Sass oder irgendwelchen
Quell-Typescript-Code, anderstranspilieren, kompilieren.
Wenn wir irgendwelche Programmiersprachenverwenden, die tatsächlich compiled
werden, ist das natürlich eineMöglichkeit, wo man das machen kann.
Man kann dynamische Sachen ausführen.
Irgendwelche Tests.
Und mit Tests meine ich jetzt zum BeispielUnit-Tests und End-to-End-Tests,
an die wahrscheinlich viele Leute denken,wenn man von Tests spricht.
Aber auch Accessibility-Testingoder Performance-Testing,
Page-Speed, Lighthouseund dergleichen.
Visual Regression-Testing.
Alles, was man irgendwogegen Code oder gegen eine
echte Umgebung testenoder laufen lassen möchte.
Und natürlich, ich schiebe meinen Code inmein Deployment-System.
Und schicke es dann an eine oder mehrereUmgebungen im Internet oder sonst irgendwo.
Wer hier hat GitHub Actions schon benutzt?
Okay, das ist eine Menge.
Dann kommen wir vielleicht nachher maldazu, wofür und wie ihr das gemacht habt.
Hauptteil jetzt dieses Talks ist Tipps undBest Practices meiner Meinung nach.
Das sind Dinge, die ich in den letzten 2,2,5 Jahren gelernt habe, angewendet habe.
Es gibt ganz, ganz viel, was man mitGitHub Actions machen kann.
Von der Syntax her, vomFunktionsumfang und natürlich
auch, wofür man es, wieman es tatsächlich einsetzt.
Also ich denke, nachdem Talk habt ihr
vielleicht 5% Überblickvon dem, was möglich ist.
Und hoffentlich viele, viele Punkte, woihr euch selber irgendwo informieren könnt.
Gerne auch mit mir sprechen oder halt dieSlides sind online.
Alles verlinkt, wo es auf der offiziellenDokumentation ist.
Ein paar Blog-Artikel und so.
Das Problem ist, ich habe das als4-Stunden-Workshop konzipiert.
Und das habe ich heute gehört.
Das ist ein 30-Minuten-Vortrag.
Kein Problem.
Ich habe gehört, das nennt man ShotgunBuffet, was wir machen.
Also ich werde euch mit ganz viel Wissenzuschießen.
Und wenn ihr Fragen habt, gerne.
Später oder sonst irgendwie.
So, wir fangen an.
Ich habe eben gesagt, so ein Workflow kannmehrere Jobs haben.
Jobs sind von der Definition her Dinge,die parallel ablaufen.
Wir haben hier drei Jobs.
Lint, Coding Standards und StaticAnalysis.
Und die machen irgendwas.
In dem Fall benutzendie jetzt hier eine Action
oder ein vorgegebenesArbeitspaket irgendwo.
Und das läuft halt parallel.
Dann gibt es dieMöglichkeit, in einem Job
verschiedene Arbeitsschrittesequenziell auszuführen.
Also wir werden hier jetzt die gleichenDinge machen.
Wir linten unseren PHP-Code.
Dann testen wir unsere Coding Standards.
Und dann werden wir statische Analysemachen.
Aber genau in der Abfolge.
Sinnvoll für diese Sache wäre vielleichtetwas anderes, so ein Zwischending.
Wir gehen nochmal zurück zu denParallelen.
Man könnte jetzt sagen, wenn ich den Codelinte.
Das heißt, ich mache erstmal nur einenreinen Syntax-Check.
Ist das valider PHP-Code?
Das ist eine Voraussetzung für die anderenbeiden Dinge.
Und das ist möglich, indem man bei denanderen Jobs sagt, dieser Job,
zum Beispiel Coding Standards, brauchteinen erfolgreich ausgeführten Job lint.
Und das gleiche Static Analysis.
Wenn wir uns das jetzt als Diagrammanschauen würden, würden wir den ersten
Job lint starten und nichts weiterpassiert.
Wenn der erfolgreich ausgeführt ist,starten wir zwei Jobs parallel,
die nichts voneinander wissen,nichts miteinander zu tun haben.
Man kann Timeouts setzen.
Wenn wir uns das jetzt mal hier anschauen.
Wir haben einen Job, der macht zwei Dinge.
Wir linten unseren Code und dann führenwir Coding Standards aus.
Es gibt einen Standard-Timeout für einenJob.
Der ist sechs Stunden.
Das heißt, wenn irgendwas inmeinem Code hängt, zahle ich
sechs Stunden an GitHubActions Minuten oder eben Geld.
Wenn mich das nicht interessiert,weil ich eh ganz viele habe, heißt das
trotzdem, dass dieser Joboder dieser Workflow einen
Runner blockiert für andereJobs, die laufen sollten.
Und dieser hängt einfach.
Das heißt, es ist immer sinnvoll,einen Timeout anzugeben in Minuten.
Das heißt wirklich Timeout Minutes.
Zum Beispiel fünf Minuten, 15 Minuten,je nachdem, was man macht.
Das kann man auf Jobebene machen.
Das kann man aber auch auf Step-Ebenemachen.
Es ist genauso sinnvoll, einen Workflowunter bestimmten Bedingungen abzubrechen.
Also wir kennen das wahrscheinlich alleoder vielleicht nur ich.
Man schreibt irgendwas, pusht das undfällt immer auf.
Oh Gott, da habe ich was vergessen.
Da fehlt ein Not.
Da habe ich was, ne, so noch schnell dasAusrufezeichen nochmal gepusht.
Dann sehe ich, oh nein, ich habe zweimaldrauf gedrückt.
Nochmal gefixt, wieder gepusht.
Jeder Push, weil ich das so definierthabe, startet meinen Workflow.
Und der läuft und läuft und läuft.
Wenn mein Workflow Sachen macht wieCoding-Standard testen, Tests ausführen,
dann weiß ich ja, ich will gar nichtwissen, was der mit keinem Not und mit
doppel Not macht, weil es war falsch.
Das heißt, ich könnte hier zum Beispieldefinieren unter dem Punkt Concurrency,
dieser Workflow ist Teil einer Gruppe.
Die definiere ich als die Workflow-ID.
Das heißt zum Beispiel,dieser Workflow lebt in
einer Datei und der hatquasi eine Bezeichnung.
Das ist diese erste Referenz,GitHub-Workflow.
Und dann habe ich GitHub-Ref.
Das wäre in meinem Beispiel, zum Beispiel,ein Commit in einem Branch.
Oder wenn ich einen Pull-Request erstelle,ist es dieser spezielle Pull-Request.
Das heißt also, wennirgendetwas in dieser Kombination
passiert, bricht diesen Workflowab, weil es gibt jemand Neuen.
Das heißt, ich habe einmalwas falsch gemacht, der wird
automatisch abgebrochen, sobaldich meinen doppel Not gepusht habe.
Und wenn ich das Richtige pushe,wird der Zweite abgebrochen.
Und nur dieser läuft weiter.
Also ebenfalls wieder Geld sparen.
Manchmal ist es abersinnvoll, einen Workflow nicht
abzubrechen oder nichtgrundsätzlich abzubrechen.
Wir haben eben gesehen,diese dritte Zeile, Cancel in
Progress, ist ein Wahrheitswert,ein Boolean, True-False.
Ich kann da aber auch ein Stück Codereinschreiben, der ausgewertet wird.
Also das hier bedeutet zum Beispiel,wenn der GitHub-Ref, also mein Branch,
mit Release anfängt, dann möchte ich dennicht abbrechen.
Und bei anderen Dingen schon.
Einfach nur als Beispiel, dass es ebenauch dynamisch möglich ist.
Unabhängig von menschlichen Triggern,wie zum Beispiel, ich pushe Code,
oder ich erstelle einenPull-Request, oder ich label etwas,
kann man auch einenWorkflow-Ablauf zeitlich steuern.
Das funktioniert mit derPOSIX-Cron-Syntax.
Das ist also das, was man auch in Cron-Tabauf einem Web-Server, beziehungsweise
einem Linux-Server irgendwo automatisierenkann.
Das kleine Problem ist, wir habenYAML-Dateien, und der Stern ist ein
Sonderzeichen, hat eine bestimmteBedeutung, also muss man den String,
der eigentlich nicht nötig ist,in Quotes packen.
Und ein Beispiel dafür ist, wir von Sydehaben eine GitHub-Action gestellt,
wo wir für jedes WordPress-Release,für jede Version von WordPress,
Stub-Dateien erstellen.
Das heißt, im Prinzip ist das die Inhaltevon WordPress ohne Inhalt.
Also alle konstanten Definitionen,alle Klassen und Funktionen ohne Inhalt.
Unser Einsatz davon ist zum Beispielstatische Analysen.
Wir benutzen Psalm, und wenn wir jetzt einPlugin entwickeln, und wir aber
WordPress-Funktionalität benutzen, sagt unsder Checker, kenne ich nicht.
Was ist das?
Und dazu kann man eben WordPress-Stubsverwenden.
Wir wollen nicht jedes Mal, wenn eine neueWordPress-Version released wurde,
und teilweise sindes ja auch, wenn es
Patch-Security-Fixes sind,mehrere, das händisch machen.
Also haben wir einfach so einen Cron-Job,der läuft halt einmal jede Woche,
glaube ich, oder so, und guckt,gibt es eine neue Version von WordPress?
Wenn ja, lädt ihr dierunter, generiert Stubs davon
automatisch, wenn eskeine gibt, passiert nichts.
Ein anderes Beispiel wäre Custom DependerBot.
Depender Bot ist ein System, das erlaubtes, irgendwelche Dependencies,
zum Beispiel Composeroder NPM, automatisch zu
aktualisieren, oder ermacht zumindest Vorschläge.
Das könnte sein, dass das nichtfunktioniert, wenn man zum Beispiel
private Registries oderRepositories verwendet, dass
man irgendwo seine eigeneComposer-Instanz hat.
Dann könnte man, genau wie Depender Botarbeitet, so ein Workflow schreiben,
der einfach jede Woche einmal guckt,mit Composer zum Beispiel, gibt es
irgendein Update, wenn ja, schlage ich demBesitzer des Repositors das vor,
als Pull-Request zum Beispiel,dann kann man machen, was man möchte.
Dann ist es manchmal sinnvoll,einen Workflow manuell zu starten.
Das könnte zum Beispiel sein, weil ichetwas testen möchte, tatsächlich auf GitHub.
Man kann Workflows auch lokal testen,nicht alles davon funktioniert gut.
Manchmal ist es aber auch sinnvoll,dass man das wirklich aufgrund von
irgendwelchen Dingen mal händisch anstoßenmöchte.
Wenn man als Trigger Workflow Dispatchhinzufügt, dann sieht man hier,
wenn man zu diesem Workflow in GitHub inseinem Repository geht, dass da dieser
Button, oder so ein Dropdown-Buttonerscheint, Run Workflow.
Der ist standardmäßig nicht da, nurwenn dieser Trigger unter anderem da ist.
Das muss nicht der einzige Trigger sein.
Dann kann ich diesenWorkflow sogar in einem
Zielbranch ausführen,so wie er jetzt definiert ist.
Dann ist es ganz oft sinnvoll,dass ich Sachen, die ich mehrmals benutze,
oder mehrmals brauche,nicht mehrmals tatsächlich
schreibe, sondernirgendwie wiederverwende.
Zum Beispiel ein Setup vonirgendetwas, Vorbereitungen
für meinen eigentlichen Job,den ich ausführen möchte.
Das geht zum Beispiel mit ReusableWorkflows.
Und so ein Workflow braucht einen TriggerWorkflow Call.
Das bedeutet, ein anderer Workflow darfdiese Datei, diesen Workflow auch starten.
Das bist du.
Der Vorteil davonist, wenn mein äußerer
Workflow gestartet wird,hat er einen Payload.
Der weiß über bestimmte Dinge Bescheid.
Wie wir eben gesehen haben, was ist meinBranch, was ist sonst irgendwas.
Und wenn ich einen Workflow, der diesenWorkflow Call Trigger hat, starte,
bekommt der genau diese Informationenweitergereicht.
Also als wäre dieser Workflow direktgetriggert worden.
Es ist halt sinnvoll, irgendwelche immerwieder aufkommenden Dinge zu abstrahieren
und an einer Stelle zu definieren und dannwiederzuverwenden.
Und man kann natürlich auch...
für diesen Reusable Workflow irgendwelcheEingabe- oder Ausgabewerte definieren,
damit dieser Workflow mit der Vergangenheitund der Zukunft quasi kommunizieren kann.
Das ist ein Beispiel.
Wir haben hier oben in Workflows MyWorkflow.
Der hat jetzt irgendeinen Trigger wie zumBeispiel Push oder Pull Request oder so.
Und in Zeile 7 sehen wir Uses.
Und dann sehen wir, es ist ein lokaler PartGitHub Workflows My Reusable Workflow.
Und der ist hier unten definiert.
Der hat den Trigger on Workflow Call,darf also von einem anderen Workflow
gestartet werden und macht dann sein Dingoder seine Dinge.
Eine ähnliche, aber etwas andere Idee isteine Composite Action.
Eben hatten wir Reusable Workflow.
Jetzt haben wir Composite Action.
Das heißt, eine Action istein Teil, also ein Teil einer
Abfolge, die irgendwo in einemWorkflow ausgeführt werden kann.
Und dieser Workflow ist dann...
Der Workflow benutzt einmal in Zeile 5Actions Checkout.
Das ist eine tatsächlicheAction, die irgendwo
definiert ist in einemeigenen Repository.
Die kann man einfach so referenzieren undverwenden.
Und dann benutzen wir in Zeile 7 einelokale Action.
Und der Part hier ist GitHub Actions unddann ist es der Name.
Und das ist, wie wir jetzt darunter sehen,der Name eines Ordners.
Und in dem Ordner muss eineaction.yaml-Datei liegen.
Die wird gesucht und dann ausgeführt.
Und hier sehen wir in Zeile 4 oder 3 und 4Runs using Composite.
Wenn man Actions schreibt, gibt es aktuelldrei Arten davon.
Einmal ist es eineJavaScript-Action oder es ist eine
Docker-basierte Action oderes ist eine Composite-Action.
Und ich würde sagen, der einzige großeUnterschied zwischen einer
JavaScript-Action und einerComposite-Action ist,
dass alles, was in dieser Action passiert,
als ein Punkt in meinem anderen Workflowsteht.
aufgelistet wird.
Also wenn ich da jetzt 13 verschiedeneandere Actions und Workflows und eigenen
Bash -Codes schreibe und so weiter,sehe ich in meinem benutzenden Workflow
einfach nur, diese Actionwurde ausgeführt und hat so
lange gedauert und isterfolgreich oder eben nicht.
Hier, wie gesagt, die Slides sind online,könnt ihr euch dann anschauen.
Das sind zwei interessanteArtikel, warum man das unter
welchen Umständen verwendensollte, was einem das bringt.
Natürlich wäre es schön, wenn man immerfunktionierende Artikel und Code schreibt,
ist aber nicht der Fall.
Manchmal muss man debuggen, was da geradeläuft.
Warum irgendwas, was immer lief,jetzt mal nicht läuft, weil man etwas
Neues quasi probieren möchte, warum esnicht so läuft, wie man möchte.
Dafür gibt es Debug-Logging.
Es ist ein Feature von GitHub Actions.
Genauso kann oder muss man manchmal einenJob, der nicht erfolgreich gelaufen ist
oder zwar erfolgreich gelaufen ist,aber irgendwie nicht das gemacht hat,
was man erwartet hat,nochmal neu starten und kann
dann sagen, den jetzt bitteim Debug -Modus starten.
Und das bedeutet, dass manche Dinge,also Actions, die ich referenziere und die
ich verwende, mehrInformationen ins Terminal
reinschreiben, was ichdann anschauen kann.
Zusätzlich kann man in seinen eigenenWorkflows oder Actions aber auch
Informationen schreiben, die nur in soeinem Debug-Modus zu sehen sind.
Das sieht so aus, dass manquasi in einem Bash-Script
ins Terminal einenbestimmten Text schreibt.
Und der ist Doppelkolon oder DoppelpunktDebug und danach dann irgendeine Nachricht.
Ein Beispiel wäre so.
Wir haben einen Job,Debug-Workflow, der hat einen
Step und zwar führe ichEcho und dann so weiter aus.
Das sehe ich nirgendwo, nicht mal inmeinem Terminal, ganz normal.
Es sei denn, ich starte diesen Debug-Mode.
Manchmal, wenn man Bash-Code ausführt,also irgendwelche Kommandos, irgendwelche
Skripte, kann es sein, dass hier in Zeile7, ein Kommando fehlerhaft sein könnte.
Das heißt, es funktioniert etwas nicht wieerwartet.
Es gibt einen Fehler auf Terminal-Ebene.
Und standardmäßig heißt es, dass unserWorkflow, also der gesamte Workflow,
nicht nur mein Step, fehlerhaft beendetwird.
Das möchte man nicht immer.
Man kann das verhindern,indem man GitHub Actions sagt,
was für eine Terminal-Umgebunggenutzt werden soll.
Also wie quasi die Shell erzeugt wird.
Das sieht zum Beispiel so aus, dassman sagt, ich hätte gerne eine Bash -Shell.
Und was auch immerda quasi als Inhalt ist, das
möchte ich quasi alsArgument übergeben werden.
Der Standard-Shell, die Standard-Shell-Definition ist Bash minus E,
was halt bedeutet,
sobald ein Skript, einKommando, ein Fehler, also
ein Nicht-Zero-Excel-Codehat, bricht alles ab.
Das wollen wir hier nicht.
Wir wollen irgendwas machen.
Warum?
Na, weil wir zum Beispielirgendetwas tun wollen,
nachdem wir wissen, es waretwas fehlerhaft oder nicht.
Das heißt, wir führenhier in Zeile 7 immer noch
diesen, diesen Befehl aus,der fehlerhaft enden könnte.
Dann fragen wir oder speichernwir diesen in Zeile 8 den
Return-Code und machen dannirgendwas und geben den genauso wieder.
Das heißt, wir wollen eigentlich nurzwischendrin noch etwas machen.
Und das könnte auch an irgendeineBedingung geknüpft sein.
Vielleicht will ich das nurmachen, wenn er wirklich
fehlerhaft ist oder wenn ernicht fehlerhaft ist oder so.
Dann gibt es die Möglichkeit,
Inline-Nachrichten an einen Pull-Request,
zum Beispiel, also in Dateien, die in einem
Pull-Request dargestelltwerden, zu schreiben.
Das machen viele GitHub-Actions,zum Beispiel Code-Checker, wo mir irgendwo
in Coding-Standards dann gesagt wird,ja, du hast hier in dieser Zeile diese und
jene Coding-Standards-Regel nichtbeachtet.
Das können wir auch selber machen.
Und zwar, indem wir entweder eine Notice,eine Warning oder einen Error loggen.
Es gibt noch weitere Sachen als die,die ich jetzt hier zeige.
Es ist ähnlich wie mit dem Debug.
Wir schreiben einen Sonder-String insTerminal.
Wir nehmen zuerst den Type, also zumBeispiel Notice.
Und dann haben wir einen absoluten odereinen relativen vom Repository gesehenen
Pfad zu einer Datei, zu einer Zeile indieser Datei und dann eben die Nachricht.
Hier wäre ein Beispiel.
Wir schreiben in die erste Zeile unsererReadme-Datei, dass die einfach klasse ist.
Das ist ein anderes Beispiel, wo wir einpaar Sachen kombinieren.
Ich führe hier in Zeile 7 Parallel-Lintaus.
Also im Prinzip prüfe ich meinen PHP-Code.
Und diese Binary, diesesProgramm erlaubt es,
die Ergebnisse alsJSON-String zu returnen.
Das speichere ich einfach in Zeile 7 ineiner Variablen.
Prüfe dann noch, ob es hier Fehler gibt.
Wenn nicht, dann bin ich fertig.
Und wenn es Fehlergibt, dann suche ich mir da
bestimmte Dinge raus,die ich dann über diese...
das kann man jetzt hier nicht ganzsehen...
die ich dann quasi so, wie wir es ebengesehen haben, über Error, File,
Line und dann Message weitergeben.
Interessant ist nämlich, dass genau dieDaten, so wie wir die brauchen,
also als Bezeichner File, Line und Messagevon Parallel-Lint zurückgegeben werden.
Und hier haben wir eben in Zeile 5gesehen, ich möchte nicht, dass wenn
Parallel -Lint Fehler feststellt,das ist ein Non-Zero-Exit, dass dann mein
Workflow beendet wird,sondern ich möchte damit
etwas machen unddann in Zeile 10 beenden.
Und in Zeile 8 sind wir mit dem Exit 0quasi rausgesprungen als ja, alles ist
gut, dann beende ich auch so, dass es gutist.
Job Summaries ist ein weiteres Feature,das angeboten wird.
Wenn es irgendwelche Dinge gibt,die man zum Beispiel ins Terminal
schreiben könnte, die aber eigentlichrelevant sind für jemanden, der überprüft,
was ist da gerade passiert, dann ist essinnvoller, das nicht im Terminal in einem
verschachtelten und erstmal nichtaufgeklappten Bereich meines Outputs zu
machen, sondern indemich tatsächlich eine Summary
für meinen Step oderfür meinen Job schreibe.
Das funktioniert interessanterweise so,dass man in eine Datei quasi reinschreibt
und wenn man fertig ist mit diesem Step,wird der Inhalt der Datei ausgelesen.
Wenn da was drin ist,wird dann das quasi als
Inhalt tatsächlichso visuell dargestellt.
Und das unterstützt Markdown.
Wir sehen hier im Beispiel, wir schreibenHello World und haben ein Emoji und
schreiben das zusätzlichzu allem, was jetzt
schon in diesem GitHubStep Summary drin ist.
Und so, ist vielleicht nicht gut zuerkennen, sieht es dann aus, in meinem
Ergebnis von meinem Workflow Run habe ichunten einen Bereich, da sehe ich jetzt
Example Summary und dann unserinterpretiertes Markdown.
Es gibt verschiedene Möglichkeiten,wie man Third Party Actions oder auch
Workflows von der Version her, vom Commither, von der Referenz her benutzen kann.
Was man oft sieht, istdie zweite Möglichkeit,
dass man sagt, ich hättegerne Version so und so.
Man kann auch einen Branch von demRepository, wo die Action lebt, verwenden.
Manchmal ist es aber vielsicherer oder sinnvoller,
dass man tatsächlicheinen Commit erzeugt.
Denn der Branch bedeutetnatürlich, ich benutze
das, was als letztesdahin gepusht wurde.
Eine Version isteigentlich nur ein Tag, kann
auch gelöscht werdenund redefiniert werden.
Und das heißt, es ist möglich,dass jemand dieses Repository irgendwie
sich aneignet und dann da schadhaften Codereinschreibt und ich benutze das in meinem
sehr privaten, sehr sensiblen Bereich mitweiß ich nicht was für Daten und denke
auch nicht daran, was dann passierenkönnte.
Wenn ich aber sage, ich hätte gern genaudiesen Commit Hash, es ist nicht möglich,
also nicht so leicht möglich, es istleider, man löscht das Repository und
setzt es neu auf und soweiter, dass man quasi
sagt, ja, ich möchteda jetzt mal was ändern.
Wenn ich einmal sage,ich hätte gern diese
Version von dieser Action,dann ist das auch so.
Jetzt könnt ihr natürlich sagen,ja gut, aber wenn ich das jetzt in 20,
30, 100 Stellen macheund da ändert sich was,
dann muss ich ja allesimmer von Hand überprüfen.
Ist das wichtig?
Muss ich das, sollte ich das benutzen odernicht?
Das ist richtig.
Das könntet ihr dann aber so umgehen,dass ihr einen eigenen Workflow schafft,
wo ihr quasi an einer Stelle für euch inder Firma, für euch privat sagt,
wenn ich diese Artvon Workflow ausführe,
benutze ich diese Actionmit diesem Commit Hash.
Wenn ihr irgendwo seht, oh, da gibt es wasNeues, prüft ihr es einmal.
Entweder wollt ihr das oder ihr wollt esnicht.
Aktualisiert eure Reusable-Seiteund sämtliche Consumer
irgendwo sind dann ebenauf dem Stand, wie ihr wollt.
Vielleicht wollt ihr sogar euren Reusable-Workflow selber taggen mit verschiedenen
Versionen, wo ihr sagt, naja, die neueVersion ist sinnvoll, aber nicht immer.
Dann könntet ihr quasi in euren Consumernsagen, ich hätte gern meinen Workflow
Version 1 und da hätte ich gerneVersion 2.
Es ist möglich, Permissions zuspezifizieren.
Das heißt, der GitHub Token, also dasStück, das Datum, an dem hängt,
was der Runner im Prinzip machen darf, kannvon euch in dem Workflow definiert werden.
Das sind die ganzen möglichen Permissionsund die Werte davon.
Und manchmal ist essinnvoll, dass ihr so anfangt,
dass ihr sagt, dusollst gar nichts können.
Und dann werdet ihr schonsehen, dann sagt GitHub Actions,
konnte nicht das und dasmachen, Permission fehlt.
Und dann könnt ihr überprüfen,okay, wenn ihr einen Action schreibt,
einen Workflow, der einen Pull-Requesterstellen soll, dann macht das schon
durchaus Sinn, dass dieser Runner einenPull-Request schreiben darf.
Zum Beispiel werdet ihr dann so eurenCustom-Workflow definieren.
Und das reicht genau für Permissions füreure Zwecke.
So, ich habe noch drei Minuten und noch120 Folien.
Nein, stimmt nicht.
Es ist möglich, dass man so ein Workflownur auf bestimmte Änderungen laufen lässt.
Also zum Beispiel sagt man, ich möchtediesen Workflow starten bei einem Push,
aber nur, wenn sich irgendeine PHP-Dateiändert.
Genauso ist es hier möglich, eineIgnore-Negation zu nutzen.
Ja, PHP-Dateien, aber keine Tests zumBeispiel.
Das Problem dabei ist, wenn man in GitHubin den Repository Settings sagt,
ich hätte gerne bestimmte Workflows,bestimmte Actions als required.
Die müssen immer laufen und die müssenauch immer successful sein.
Das Problem ist nämlich, ich gehe nocheinmal zurück.
Wenn GitHub sieht, das soll nur ausgeführtwerden bei PHP-Änderungen und es ändert
sich keine PHP-Datei, dann sagt GitHub,ja, dann mache ich halt nichts.
Und das ist für GitHub ein nichterfolgreich ausführen.
Manchmal wollen wir, dass dieser Workflow,diese Action ausgeführt wird.
Aber wenn sie nichts macht, dann ist unsdas egal.
Dann ist das erfolgreich für uns.
Das ist nach meinem Stand nur möglich übereine externe Action.
In Zeile 6 hier dorny/paths-filter.
Das heißt, wir werden auf jeden Fallunseren Workflow immer ausführen.
Und in dem Workflow selber sehen wir,was hat sich getan?
Will ich irgendwas machen oder nicht?
Dann sehen wir halt hier zumBeispiel, ich möchte nur etwas
machen, wenn sich im Composer-Bereichwas geändert hat.
Composer.json oder lock.
Dann kann man hier weiter überprüfen,ja, gibt es das oder gibt es das nicht?
Dann mache ich irgendwas.
Das erlaubt noch ganz viel mehr.
Zum Beispiel kann man Gruppen definieren.
Also ich sage einmal hier in Zeile 2,ich möchte Workflows haben.
Also meine Workflow und Action-Dateien.
Dann habe ich NPM-Dateien, die beinhaltenWorkflows und auch weitere Sachen.
JavaScript und Styles und so weiter.
Und dann kann ich ganz genau hier sagen,was wann passieren soll.
Ich würde gerne noch einmal hier nochzurückkommen.
Dependabot hatten wir eben gesagt.
Dependabot unterstützt auch GitHubActions.
Also sämtliche Third-Party Actions undWorkflows kann Dependabot euch auch
vorschlagen zu aktualisieren.
Und dann habe ich hier einfach,nur damit ihr es schon einmal gesehen
habt, eine Liste von sinnvollen Actions,aber auch von Reusable Workflows.
Und bin sehr daran interessiert,was ihr so nutzt.
Vielleicht können wiruns über Twitter oder
hier oder LinkedIn oderirgendwo austauschen.
Das waren 120 Slides in 40 Minuten.
Dankeschön.
Genau, hier sind die Folien schon online.
Ich weiß nicht, haben wir ein,zwei?
Fragen oder besser später?
Thorsten, ich habe eine Frage.
Also im Moment ist es so, wir haben eineArt Framework gebaut als Repository auf
GitHub, was privat ist.
Und die Idee war sozusagen, diesesFramework als Repository in verschiedenen
anderen Repositories wieder zu verwertenund die halt dort in verschiedenen
Templates, in Themes sozusagen zuüberschreiben.
Die Idee ist abergewesen, dass wir das über
den GitHub Shared, alsodie Submodules machen.
Da ist mal meine Frage an dich.
Gibt es vielleicht eine andere,bessere Möglichkeit?
Also ich weiß, dass du über NPM diePackages könnte man nutzen.
Hast du vielleicht noch andere Vorschläge,was man so machen könnte, um halt eine
Zentralisierung von Code bereitzustellen,die man halt in anderen Repositories
wiederverwerten kann?
Ja, können wir gerne im Detail nochdarüber sprechen.
Da sehe ich jetzt ehrlich gesagt nicht denBezug hierzu.
Das ist eher, dass du irgendein anderesSystem nutzt, um Code...
verfügbar zu machen.
Es geht darum, dass halt diese Shared auchin diesen GitHub Actions aufrufbar sind,
damit halt den Code amEnde released werden kann,
weil das alles dann dieAbhängigkeiten zusammenkommen.
Ja, also der Bezug zu GitHub Actions,du kannst ausführen, was du möchtest.
Du hast eine, standardmäßigeine Linux Shell und kannst dir
irgendwelche Dateien runterladenund interaktiv ausführen.
Du kannst ein Docker Image bauen.
Also da ist dir, solange du quasi denZugang, die Authentication irgendwie...
managen kannst, kannst du in deinemWorkflow machen, was du willst.
Der kann auch irgendwo in einem Repositoryliegen, privat oder nicht privat,
wo du diese reusable Workflows anbietestund die dann an verschiedenen Stellen nutzt.
Du kannst auch ein GitHub Repository alsTemplate Repository erstellen.
Das heißt, jedes Mal, wenn du eine neueArt von diesem, was auch immer,
wofür das Framework jetztda ist, wenn du das baust,
erstellst du ein neuesRepository, wo schon Inhalt drin ist.
Das heißt, du hast dann quasi nach demErstellen nicht mehr den Bezug zu,
wo kam das jetzt eigentlich her?
Aber du hast dann quasi einen StarterInhalt.
Da gibt's verschiedenste Möglichkeiten.
Müsste man mal drüber sprechen,was jetzt genau euer Kontext da ist.
Ja, gerne.
Gut, dann.
Ich entscheide nicht, ob wir noch Zeit fürFragen haben.
Dankeschön erstmal für den Talk.
Es gibt ja eine Action von dem neuenPlugin Check.
Genau.
Der Check.
Der Check enthält ja auch einePrüfung des Stable Tags, was
natürlich für die Entwicklungwahnsinnig unpraktisch ist.
Was wäre da der Ansatz, quasi,kann man das an der, also für einen
Release müsste ja wahrscheinlich gehen,quasi nicht für jeden Commit, sondern
quasi erst bei dem Erstellen eines Tagsdie Action ausführen zu lassen,
damit man, oder kann icheinzelne Regeln im Plugin
Check unterdrücken, dasser diese Regeln ausführt?
Oder was wäre da der Ansatz, das nutzbarzu kriegen?
Also ich habe den tatsächlich als GitHubAction noch nicht benutzt.
Das heißt, ich weißnicht, was in der GitHub
Action möglich ist,über Inputs oder Secrets.
Ich weiß nicht, was als Programm beimPlugin Check konfigurierbar ist.
Aber ganz wichtig ist das, was du indeinem Kontext ausführst, ist nicht diese
Action, sondern ein Workflow, den duselber schreibst.
Und diese Action ist ein Bestandteil.
Das heißt, du kannst definieren,wann du das benutzen möchtest.
Und dann kannst du das auch ausführen.
Und wie gesagt, wenn etwas konfigurierbarist, kannst du das halt da machen.
Das muss man sich wirklich mal anschauen.
Was ist in dieser Action möglich?
Was ist vielleicht auf EnvironmentVariable oder wie auch immer möglich,
dass man quasi an das Skript, dasausgeführt wird, weitergibt?
Oder kannst du vielleicht selber eineVersion davon machen?
Also du bist ja nicht gezwungen,für jeden Commit, der irgendwie in dein
Repository kommt, diese Actionauszuführen.
Ich weiß nicht, ob das halbwegs antwortet.
Gut.
Dankeschön.
Dann...
Du hattest erwähnt, dass man diesen Timernur einstellen kann pro Workflow oder Step.
Kann man das auch irgendwie globaleinstellen für seinen User?
Dass man das nicht immer reinschreibenmuss?
Das glaube ich nicht.
Also du kannst das für einen Job machen.
Du kannst es für einen Step machen.
Aber auch nur, wenn dieser Step nicht quasinur Ausführen einer anderen Action ist.
Weil dann muss der Timeout da definiertwerden.
Aber global habe ich das noch nichtgesehen.
Noch nicht mal global in einer Datei füralle Jobs.
Also es gibt ein Defaults Key.
Da kann man zum Beispiel sagen,überall wo ich ein Bash, also wo ich Run
benutze, wo ich quasi Bash-Code ausführeoder wo ich ein Script-Code, Terminal-Code
ausführe, möchte ich sagen, das ist dieseund jene Shell zum Beispiel.
Oder RunsOn zum Beispiel.
Timeout gibt es nicht.
Ich habe mich bei manchen Dingen schongefragt, wäre das nicht sinnvoll,
wenn man das quasi als Default zumindestfür diesen Workflow konzipiert.
Vielleicht ist die Denke dahinter,dass man gar nicht zu komplexe Workflows
bauen sollte, sondern immernur kleine Sachen und die
dann miteinander verknüpftund wiederverwendbar macht.
Aber weiß ich nicht, wasda die Gründe sind, warum
es manche Dinge nicht gibtoder manche Dinge schon.
Gut, dann danke schön und viel Spaß noch.