#31 Ich automatisiere mir die Welt wie sie mir gefällt (mit GitHub Actions)

Schuftest du noch oder automatisierst du schon?

Heute gehts um die Faulheit von Entwicklern: Wir sprechen über GitHub Actions - Was es ist, wozu man es benutzen kann, wie es das eigene Leben erleichtern kann, wo der Unterschied zu Jenkins ist, wie das Engineering Kiosk es selbst einsetzt und welche Use-Cases von der Community oft genutzt werden.

Bonus: Warum LinkedIn einen HTTP Status Code 999 sendet, wann wir Programmiersprachen wie Unterhosen wechseln und was Michael "Bully" Herbig mit der ganzen Sache zu tun hat.

Sprungmarken

(00:00:00) Intro

(00:00:31) E-Mails von GitHub

(00:03:11) Deutschsprachige Tech Podcasts: Eine kuratierte Liste von deutschsprachigen Tech-Podcasts

(00:07:35) Heutiges Thema: Automatisierung mit GitHub Actions und Attribut bei Software Engineers: Disziplin oder Faulheit

(00:10:07) Was GitHub Actions ist und was Wolfgang bereits darüber weiß

(00:14:47) Wie sieht die GitHub Automation beim GermanTechPodcast Repository aus?

(00:26:19) Einen GitHub Actions Workflow in einem anderen Repository triggern

(00:29:03) GitHub Actions und Passwörter, API-Keys und andere Geheimnisse und Isolation von einzelnen GitHub Actions

(00:34:56) Was passiert bei der Engineering Kiosk Website, wenn das GitHub Actions-Event entgegen genommen wird

(00:39:50) GitHub Actions im professionellen Umfeld, ist Jenkins noch relevant und Limitierungen mit privaten Netzwerken

(00:46:30) Link-Checking in GitHub Actions mit Lychee und automatische GitHub Issue Erstellung

(00:50:21) Eigene Profile-README mit GitHub Actions updaten

(00:52:52) Wo liegen die GitHub Action Workflows?

(00:53:37) GitHub Action um Inner Source und Cross-Team Contributions zu fördern

(00:55:25) GitHub Actions um Stale Issues zu schließen

(00:56:59) Aufruf um GitHub Actions zu testen und neue Contributor zu begrüßen

(00:58:28) Feedback und Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:02 - 00:00:27)

Schuftest du noch oder automatisierst du schon? Das ist die Frage, die uns in dieser Episode begleitet. Und damit willkommen zu einer neuen Episode vom Engineering Kiosk. Heute geht es um Automatisierung, im Speziellen um die Automation und Workflow Engine GitHub Actions. Wir klären, was das Ganze ist, welche Möglichkeiten es zur Automatisierung neben Continuous Integration noch so gibt und präsentieren diverse Beispiele aus der Praxis. Viel Spaß und los geht's!

Wolfi Gassler (00:00:31 - 00:00:46)

Okay, dank dir habe ich jetzt jeden Tag hunderte E-Mails mehr in meinem Posteingang, die ich meistens alle lösche, direkt ohne sie zu lesen. Und die Aufgabe von dir ist jetzt in dieser Episode mir zu erklären, warum ich diese E-Mails bekomme und warum die Sinn machen.

Andy Grunwald (00:00:46 - 00:00:54)

Die erste Frage, die ich mir stellen würde, warum löscht du E-Mails, die ich dir schreibe? Das ist schon so eine kleine Beleidigung, würde ich sagen.

Wolfi Gassler (00:00:54 - 00:00:57)

Aber die einzige sinnvolle Aktion, die man mit diesen E-Mails machen kann.

Andy Grunwald (00:00:57 - 00:01:05)

Gegebenenfalls könnte dies auch deine Art und Weise sein, zukünftige Projektarbeit mit mir zu kündigen, ohne es mir direkt sagen zu wollen.

Wolfi Gassler (00:01:06 - 00:01:35)

Also vielleicht zur Erklärung, es sind eigentlich keine E-Mails direkt von Andi, sondern von GitHub, die ich da ständig in meine Mailbox gespült bekomme. Macht das eigentlich Sinn? Kann ich die deaktivieren? Kann ich da nur die sinnvollen E-Mails irgendwie rausfiltern? Und nicht die ganzen, vor allem dieser Depender-Bot, der mir da täglich irgendwelche E-Mails schickt. Und dazwischen sind vielleicht ja auch sinnvolle E-Mails. Das ist wirklich schwer dann rauszufinden. Wenn jemand irgendwo ein Pull-Request sendet, ist es teilweise sogar schwierig, das rauszubekommen, welches jetzt da sinnvoll ist, ohne dass ich wirklich hunderte E-Mails liese.

Andy Grunwald (00:01:35 - 00:02:14)

Die erste Frage ist für mich, was ist sinnvoll für dich? Das ist ja so wie, kann ich mir nur schöne Kleidung kaufen? Kann ich mir nur leckere Getränke zubereiten? Klar kannst du das, aber was ist das denn? Also was ist sinnvoll? Und die zweite Geschichte ist, vielleicht solltest du dir mal diesen Engineering-Curse anhören. Der hat mal eine Episode gemacht zum Thema Produktivität. Und Achtung, vielleicht wurde es nicht in der Episode erwähnt, aber Produktivität bedeutet auch, sich ordentliche E-Mail-Filter einzurichten. Kennst du sowas? E-Mail-Filter? Wenn diese E-Mail reinkommt, die einen gewissen Betreff hat von einem gewissen Absender, dann label sie automatisch und boxier sie sofort in den Papierkorb.

Wolfi Gassler (00:02:14 - 00:02:18)

Das haben wir übrigens in Episode 13 der Produktivitätsfolge besprochen.

Andy Grunwald (00:02:18 - 00:02:20)

Wir? Anscheinend warst du ja nicht dabei.

Wolfi Gassler (00:02:21 - 00:02:36)

Ja, ich habe aber auch erklärt, dass ich so dieses Getting-Things-Done-Modell mit der Mailbox, mit der Inbox habe, wo alles reinkommt und ich das dann dementsprechend filter. Die Frage stellt sich ja für mich immer, wenn ich einen Filter erstelle und irgendwie alles lösche, warum kann ich das Ding nicht einfach abbestellen?

Andy Grunwald (00:02:36 - 00:03:23)

Du kannst auf GitHub deine E-Mail-Notifications einstellen. Aber ich bin mir nicht sicher, ob es so fein granular geht. Ich glaube, du kannst es auf Repository-Basis einstellen, aber nicht auf Aktionsbasis. Also ich glaube, du kannst nicht sagen, alle E-Mails von Pull-Requests, die vom Dependabot erstellt wurden, sende sie nicht raus. Ich glaube, das geht nicht. Zurück zu deiner Frage, ich sollte dir erklären, warum du so viele E-Mails bekommst. Weil ich am Wochenende wieder Zeit hatte. Ich hatte am Wochenende wieder Zeit, an unseren Seitenprojekten zu arbeiten, wie zum Beispiel am Engineering-Kiosk, wie zum Beispiel an unserer Engineering-Kiosk-Webseite oder an unserem neuen Projekt German Tech Podcast. Möchtest du kurz den Hörerinnen und Hörern erklären, was unser neuestes Projekt German Tech Podcast ist und warum ich das auf Englisch sage, obwohl es was mit Deutsch zu tun hat? Wolfgang, bitte sehr.

Wolfi Gassler (00:03:24 - 00:04:25)

Es klingt fast, als würdest du mir ständig diese Referenzen zu unseren bisherigen Episoden auflegen, also bezüglich Englisch, Folge 26, Episode 26. My English is not so yellow from the egg. Kann sich gern jeder mal anhören. Geht's um die englische Sprache und warum man vielleicht in der IT mehr Englisch verwenden sollte, auch bei GitHub-Projekten. Und drum heißt unser neuestes GitHub-Projekt German Tech Podcast. Und der Hintergrund ist eigentlich, Wer uns auf Twitter verfolgt, hat vielleicht die Kommunikation zwischen uns und Nils mitverfolgt, der ja Podcasts immer hört, während er läuft und joggen geht und er würde gern öfters pro Woche das Ganze machen und nachdem wir nicht deliveren können, so oft pro Woche, haben wir uns überlegt, es gibt ja auch ganz viele andere interessante Tech-Podcasts, die noch dazu deutschsprachig sind. Und die sammeln wir gerade in einem GitHub-Repository, damit sie für jedermann und jeder Frau zugänglich sind und ihr einfach noch mehr Content absaugen könnt, wenn ihr zum Beispiel laufen geht.

Andy Grunwald (00:04:25 - 00:04:43)

Und jetzt ist es natürlich nicht so, als haben wir einfach alle Podcasts genommen, die wir kannten und da reingepackt, sondern wir haben uns auch ein bisschen links informiert und rechts informiert. Und ich muss zugeben, ich war sehr, sehr überrascht, was für ziemlich geile deutsche Podcasts es doch so auf dem Markt gibt oder deutschsprachige.

Wolfi Gassler (00:04:43 - 00:04:58)

Ganz wichtig. Wobei, wir haben noch kein österreichisches dabei, oder? Aber es gibt immer ein paar österreichische Hosts teilweise, die da mit dabei sind. Also, falls ihr einen österreichischen Podcast kennt, im Tech-Bereich, unbedingt, her damit. Oder einen Schweizer Podcast.

Andy Grunwald (00:04:58 - 00:05:12)

Auf jeden Fall ist meine Podcast-Liste jetzt sehr lang geworden. Aber wir haben schon einen schweizerischen Podcast dabei. Und Achtung, ein Wortwitz. Kannst ja schon die Domain denken. Der heißt Code-Stammtisch. Was heißt das ist die Top Level.

Wolfi Gassler (00:05:12 - 00:05:30)

Domain von der Schweiz? Ich habe ehrlich gesagt diese Domains finde ich immer extrem schwierig zu merken, weil man da nie weiß, war das jetzt dieser Name.com oder war das der letzte Teil abgeschnitten irgendwie und dann in der Domain Endung, am Ende muss ich doch wieder googlen.

Andy Grunwald (00:05:31 - 00:05:38)

Ich glaube, das erste Mal, wo ich diese Domainspielchen gesehen habe, war bei der Bulli-Parade. Kennst du die Bulli-Parade?

Wolfi Gassler (00:05:38 - 00:05:39)

Ja, vom Namen her.

Andy Grunwald (00:05:39 - 00:05:46)

Die Bulli-Parade war, ich würde schon fast sagen, der Vorgänger von TV Total von Stefan Raab, wenn du so möchtest, halt nur nicht von Stefan Raab.

Wolfi Gassler (00:05:46 - 00:05:47)

Und das ist schon alt.

Andy Grunwald (00:05:47 - 00:05:50)

Aber der hatte immer die Domain bulli-para.de.

Wolfi Gassler (00:05:51 - 00:05:56)

Ja, ist mir einfach zu mühsam, diese Endungen. Aber der Podcast ist wenigstens gut, oder?

Andy Grunwald (00:05:57 - 00:05:59)

Ich muss zugeben den Coach Stammtisch habe ich noch nicht gehört.

Wolfi Gassler (00:05:59 - 00:06:02)

Weil du kein Schweizerisch verstehst.

Andy Grunwald (00:06:02 - 00:07:05)

Nein, ich habe ein bisschen recherchiert und habe die Podcasts, die ich gefunden habe, die mir Techie aussahen, habe ich als GitHub-Issue erstellt mit dem mit der Aufgabe, dass man sich die doch mal reviewen sollte. Und da kam ich halt auch nicht zu, aber wir haben jetzt glaube ich 16 oder 17 Podcasts, habe ich gereviewt, mal reingehört. Da ist wirklich alles bei, von Focus on DevOps, Focus on Linux, das ist ein spezieller Podcast von DevOps und Linux. Dann sowas wie Open Source Couch oder Open Source in der Industrie, auch sehr schön. Da gibt es halt ziemlich viele Storys, wie Open Source bei BMW zum Beispiel eingesetzt wird und was für Herausforderungen damit. die programmierbar ist ebenfalls dabei neuen schönen talk to do cast, die haben immer so kleine folgen immer zu einem thema wie api versionierung natürlich auch etwas frontend lastigeres wie working draft, oder natürlich auch was gesellschaft relevantes wie netzpolitik oder logbuch netzpolitik aber auch klassische news folgen wie von der t3 in news industry.

Wolfi Gassler (00:07:06 - 00:07:24)

Jetzt ist dieser Schweizer Podcast gar nicht auf unserer Webseite, weil wir haben auf unserer Webseite so eine Sektion, wo wir die auch zusätzlich noch auflisten für alle, denen das Github Markdown Format nicht ausreicht. Ist da jetzt deine Automation kaputt, Andi, die du gebaut hast, die alles zusammen klebt und zusammenführt?

Andy Grunwald (00:07:24 - 00:07:27)

Nee, ich hab doch gerade gesagt, der ist noch im Review, der ist noch als Github.

Wolfi Gassler (00:07:27 - 00:07:29)

Ah, okay, der ist im Review.

Andy Grunwald (00:07:29 - 00:07:30)

Ich hab ihn noch nicht reingehört.

Wolfi Gassler (00:07:31 - 00:08:00)

Weil eigentlich um diese Automation geht's heute. Andi hat natürlich wieder klarerweise Automation first. Alles automatisiert, was nur irgendwie geht. Und diese Automation ist mittlerweile so umfangreich, dass wir uns mal überlegt haben, okay, wir könnten eine Episode machen nur zu den GitHub Actions und zu den ganzen Automations, die Andi so immer baut in GitHub Actions. Und nachdem das ein richtig cooles System ist, ich sehr wenig nutze, hab mir gedacht, ich lass mir das einfach mal von Andi erklären und im Idealfall vielleicht interessiert es euch auch.

Andy Grunwald (00:08:01 - 00:08:28)

Und das ist natürlich auch der Grund, warum du so viele E-Mails bekommst. Weil ich a.) sehr viel automatisiere und b.) bis die Automatisierung läuft, schlagen diese Builds natürlich fehl und bei jedem Fehlschlag bekommen die Leute mit Schreibzugriff das Repository eine E-Mail. Bevor wir aber wirklich ins Thema starten, Welches Attribut findest du wichtiger bei Software Engineers? Disziplin oder Faulheit?

Wolfi Gassler (00:08:28 - 00:08:30)

Ist das jetzt schon der Anfang von irgendeinem Flachwitz?

Andy Grunwald (00:08:31 - 00:08:34)

Nee, nee, das ist jetzt wirklich themenrelevant hier meines Erachtens nach.

Wolfi Gassler (00:08:34 - 00:08:37)

Du meinst, was mir wichtiger ist bei einer Person?

Andy Grunwald (00:08:38 - 00:08:54)

Bei einer Person, die im Software-Engineering-Bereich arbeitet, ist dir wichtiger, dass diese Person diszipliniert ist, oder ist dir wichtiger, dass diese Person von Natur aus faul ist? Und jetzt sag nicht, beides wäre toll, bla bla bla, es gibt nur, du kannst nur entweder oder, ja? Du musst dich jetzt entscheiden.

Wolfi Gassler (00:08:55 - 00:08:56)

Ja, eindeutig Faulheit.

Andy Grunwald (00:08:56 - 00:08:57)

Begründung?

Wolfi Gassler (00:08:57 - 00:09:15)

Ja, weil ich selber so faul bin und man will ja immer ähnliche Leute im Team haben. Wobei in dem Fall will man vielleicht eigentlich Leute im Team haben, die mehr arbeiten. Aber ich weiß nicht, ob das mit Disziplin verbunden ist. Ich bin für die Faulheit. Die Leute wissen, wie man automatisiert und Sachen vereinfacht. Behaupte jetzt einfach mal.

Andy Grunwald (00:09:15 - 00:10:08)

Klingt, klingt gut. Ich würde mich persönlich so einschätzen, dass ich schon sehr diszipliniert bin bezüglich mir sehr viel Methoden geschaffen habe, immer wieder an alles zu denken. Dennoch bin ich es satt, ich bin es leid, diese einfachen dummen Dinge zu machen und da bin ich halt tierisch faul und da automatisier ich mir die weg. Und da kommen wir dann heute zum Thema GitHub Actions und wir erzählen euch einfach mal ein paar Storys, was ich so in meinem Leben in den letzten fünf Jahren alles so wegautomatisiert habe und speziell meines Erachtens nach hat das alles einen neuen Höhepunkt erreicht mit dem ganzen Engineering Kiosk, weil gefühlt habe ich da alle kleinen dummen Aufgaben wegautomatisiert. Und wie, das erzählen wir euch gleich anhand vielen kleinen Storys. Aber Wolfgang, erzähl mir mal ganz kurz bitte, was weißt du denn schon über GitHub Actions?

Wolfi Gassler (00:10:09 - 00:10:41)

Relativ wenig, aber ich möchte nur im Vorhinein sagen, ich habe natürlich auch beim Engineering Kiosk alles wegoptimiert, wegautomatisiert und diese Automatisierung nennt sich Andi. Also bei mir war das relativ einfach, das haben wir jetzt abgehackt, aber du musst es ja auch irgendwie automatisieren, diese ganzen Sachen, also da kommen ja dann die GitHub Actions mit rein. Ich habe GitHub Actions verwendet, war aber bisher meistens irgendwie copy-based, um irgendwas zu bauen, Docker-Image im Hintergrund zu bauen oder vielleicht mal was simples irgendwo im Hintergrund einfach zu bauen, bevor man das deployed, zum Beispiel zu Netlify.

Andy Grunwald (00:10:41 - 00:11:09)

Da muss ich einmal kurz einspringen. Netlify läuft nicht über GitHub Actions. Netlify wird auf Basis eines GitHub-Webhooks getriggert und du findest die Netlify-Build-Action zwar als Approval-Step für deine Pull-Request und kannst du da anschalten, sie ist aber keine GitHub-Actions. Das liegt daran, dass Netlify selbst eine GitHub-App ist. Es kommt dasselbe bei raus, dass es eine Automatisierung ist. Es ist aber keine Automatisierung von GitHub-Actions selbst.

Wolfi Gassler (00:11:09 - 00:11:41)

Ja, Netlify übernimmt dir da sehr viel. Aber wenn du woanders hingeployst, musst du dir das natürlich selber bauen. Und dann bietet sich natürlich das Ganze an. Aber erklär mal, wie gesagt, bei mir war das ja immer Copy und Paste und mein Verständnis war eigentlich immer, man kann da eigentlich alles ausführen. Stimmt das oder habe ich da irgendwo Grenzen? Oder kann ich da wirklich eigentlich jeden Code in irgendeiner Form ausführen? Also es ist so wie ein Docker oder so, dass ich mir da einfach irgendwie starten könnte und dann macht halt dieses Docker-Image, was ich auch immer diesem Docker-Image beigebracht habe.

Andy Grunwald (00:11:42 - 00:12:29)

Also die Antwort ist ja. GitHub Actions ist generell erstmal eine sogenannte Automation Engine. Und diese Automation Engine hat Inputs und Outputs. Inputs ist unter anderem eine sogenannte Trigger. Wann startet diese Automation? Wann startet ein Automation Workflow? Das kann auf Basis von einer Zeit sein. Klassisch wie ein Linux System, ein Cron Job. Das kann auf Basis eines Events sein. Ein Pull Request kommt rein. Ein neuer Comet wurde auf einem bestimmten Branch gemacht. Ein Issue wurde erstellt. Sowas halt, Events. Oder du kannst sie natürlich auch manuell triggern. Und was du dann als Automationsworkflow wirklich machst, das definierst du selbst. Das kann natürlich wirklich alles sein. Alles, was du coden kannst. Da gibt's natürlich fertige Bausteine, sowas wie Lego-Bausteine, die kannst du dir reinziehen und so weiter und so fort.

Wolfi Gassler (00:12:29 - 00:12:44)

Und woher kommen diese Lego-Bausteine? Weil ihr da schon gesehen habt, dass das eigentlich wie jetzt bei Docker-Images oder so läuft. Ihr habt da auch von irgendwelchen Usern irgendwelche Lego-Bausteine reingezogen. Woher kommen die dann? Ich habe ja wirklich nur copy-based in den meisten Fällen gemacht.

Andy Grunwald (00:12:44 - 00:13:26)

Die kommen entweder aus anderen Git-Repositories, aus anderen GitHub-Repositories oder aus deinem eigenen Repository oder von diesem GitHub-Marketplace. Und von diesem GitHub-Marketplace, da gibt es dann freie Actions, nennt sich sowas, oder halt bezahlbare Actions, aber die meisten sind frei. Was macht man mit diesen Automation-Workflows? Der ganz, ganz klassische Anwendungsfall ist eigentlich CICD, Continuous Integration, Continuous Delivery, Continuous Deployment. Bei jedem Push, bei jedem Commit baust du deine Software, verifizierst deine Software, lässt die Unit Test laufen, vielleicht noch ein Code Linter oder ähnliches. Das ist so der ganz klassische Anwendungsfall von GitHub Actions. So wie viele Firmen das auch mit Jenkins machen oder CircleCI oder ähnliches.

Wolfi Gassler (00:13:27 - 00:13:38)

Das heißt, du hast dann, wenn du ein Pull-Request zum Beispiel machst, dann hast du automatisch diese Checks und bekommst eingeschrieben in den Pull-Request. Sind die Checks erfolgreich durchgelaufen? Ist alles okay? Ist there already too much?

Andy Grunwald (00:13:38 - 00:14:40)

Genau, ich mache ein Pull-Request und wenn mein Projekt Unit-Tests hat und Integration-Tests oder Tests auf einem gewissen Coding-Standard, Dann kann ich die laufen lassen und wenn der Bild dann fehlschlägt, dann kommt in deine Pull-Request ein rotes X und dann im besten Fall sollte der Repository-Owner diesen Pull-Request nicht mergen, weil es ist ein rotes X, weil deine Tests nicht erfolgreich waren. Und wenn diese erfolgreich waren, sind sie grün. Und dann kannst du sogar noch weitergehen. Du kannst sagen, eine Auto-Merge-Funktionalität, also das bedeutet, wenn du dem Prozess und deiner Testabdeckung und deinen Checks wirklich so vertraust, kannst du sagen, immer wenn ein Pull-Request kommt und alle meine Checks laufen gut, dann kannst du Auto-Merge machen, dann geht das automatisch durch. Sollte man gegebenenfalls bei Open-Source-Projekten jetzt nicht immer so aktivieren, weil das bedeutet, dann kann ich natürlich immer irgendwelchen Code reinschleusen und muss nur zusehen, dass die Tests passen. Aber bei manchen Firmen, in manchen Repositories, wo man seinen Contributoren vertraut und allem drum und dran, kann man das machen und so natürlich einen relativ schnellen Release und Produkt-Cycling kriegen.

Wolfi Gassler (00:14:41 - 00:14:50)

Wenn wir jetzt zu unserem German-Tech-Podcast-Repository gehen, hast du da irgendwie einen Check eingebaut? Für irgendwas? Für Pull-Requests?

Andy Grunwald (00:14:50 - 00:14:51)

Ja.

Wolfi Gassler (00:14:51 - 00:14:52)

Und zwar?

Andy Grunwald (00:14:52 - 00:14:59)

Dafür muss ich ganz kurz erklären, wie dieses German-Tech-Podcast-Repository aufgebaut ist. Und wir verlinken das natürlich auch in den Shownotes.

Wolfi Gassler (00:14:59 - 00:15:07)

Jetzt kommt schon wieder diese Politikerantwort. Bevor ich diese Frage beantworte, muss ich noch erklären, was ich eigentlich im Sinne führe. Okay, bitte schieß los.

Andy Grunwald (00:15:08 - 00:15:47)

Ich möchte nur sagen, dass ich nicht so der Freund von Politik bin und allem drum und dran, aber hier ist das wirklich nur Kontext geben, damit man diesen ganzen Podcast, diese Episode auch komplett versteht. Generell ist dieser German Podcast, German Tech Podcast Repository ähnlich wie so eine Awesome List. Das bedeutet, wir haben eigentlich nur eine ganz klassische Liste von irgendwelchen Projekten, von irgendwelchen Podcasts in einer README gelistet. Doch ich dachte mir, ist ja ein bisschen doof, wenn wir da nur ein paar Links in so einem Markdown-File haben. Deswegen lass uns mal ein bisschen mehr draus machen. Jeder Podcast hat eine eigene YAML-Datei. Und pro YAML-Datei haben wir ein paar Informationen.

Wolfi Gassler (00:15:48 - 00:15:56)

Ich möchte übrigens für das Protokoll noch erwähnen, ich wollte unbedingt Jason, Andy hat mich nicht gelassen, jetzt sind wir bei YAML wieder und kämpfen mit Whitespaces.

Andy Grunwald (00:15:56 - 00:16:53)

Deswegen lassen wir den Wolfgang am besten mal nicht an unseren Quellcode. Wenn Leute ihren Editor nicht unter Kontrolle haben dann sollte man das am besten so lassen. Und deswegen hat man natürlich auch GitHub Actions mit einem YAML-Lint. Dazu komme ich in einer Sekunde. Jeder Podcast, jeder deutsche Tech-Podcast hat eine eigene YAML-Datei. Da stehen zum Beispiel Informationen drin wie, was ist der Spotify-Link, ein paar Tags wie DevOps oder Cloud, was ist der Name und was ist die Webseite. Und wenn du jetzt, Wolfgang, auch mal wieder deine Hände dreckig machen möchtest, das Repository klonst und mal ein Pull-Request machst, um zum Beispiel Code Stammtisch, diesen Schweizer Podcast, zu kontribuieren, Dann legst du eine neue YAML-Datei an, packst die ganzen Metadaten da rein und machst ein Pull-Request. Und wenn du ein Pull-Request machst, dann wird unter anderem eine GitHub-Action getriggert, die alle YAML-Dateien nimmt und prüft, ob die YAML-konform sind. Das bedeutet, ob du Tabs genutzt hast oder Whitespaces, ob du Fehler hast und so weiter und so fort.

Wolfi Gassler (00:16:54 - 00:17:01)

Überprüft diese Action auch, ob du die richtigen Felder hast in YAML? Also so ein Schema, so eine Schemaüberprüfung?

Andy Grunwald (00:17:01 - 00:17:03)

Aktuell noch nicht. Wäre aber mal eine Idee.

Wolfi Gassler (00:17:03 - 00:17:10)

Gibt es sowas für YAML überhaupt? Aber das braucht ja kein Mensch. YAML ist so ein grausames Format. In JSON hat man sowas natürlich.

Andy Grunwald (00:17:10 - 00:17:19)

Also ich habe jetzt gerade nur mal YAML Schema bei Google eingegeben. Der erste Treffer heißt Schema Validation for YAML und die Domain ist JSON Schema Everywhere.

Wolfi Gassler (00:17:22 - 00:17:24)

Wundert mich überhaupt nicht.

Andy Grunwald (00:17:24 - 00:17:44)

Es gibt anscheinend sowas. Habe ich aber noch nicht. Es ist aber auch nicht der einzige Test, den ich dann mache, sondern ich führe dann noch ein paar andere Checks aus, wie zum Beispiel, ob unsere Applikation noch kompiliert und so weiter und so fort. Aber generell merken wir kein invalides YAML in diesem Repository aufgrund des GitHub Action Checks.

Wolfi Gassler (00:17:44 - 00:18:09)

Ich möchte übrigens auch gleich wieder darauf hinweisen, wir haben schon einen externen Bull-Request bekommen. Vielen Dank an die Sandra. Und natürlich war es wieder eine Frau. Auch das letzte Mal, wo wir um Bull-Requests gefragt haben, war der erste Bull-Request wieder von einer Frau. Also irgendwie scheint es so zu sein, dass wir mehr Bull-Requests von Frauen bekommen, was uns natürlich sehr freut. Ich glaube, wir haben überhaupt noch keinen männlichen Bull-Request bekommen, oder? Extern.

Andy Grunwald (00:18:09 - 00:18:10)

Weiß ich leider nicht, tut mir leid.

Wolfi Gassler (00:18:10 - 00:18:28)

Nur so mal als Ansporn an alle Männer. Aber was passiert dann als nächster Schritt? Du prüfst die YAML-Dateien, ob alles kompiliert, ob alles funktioniert. Was passiert dann als nächster Schritt? Kommt dann schon unser manuelles Review mit rein oder kommt da noch was dazwischen?

Andy Grunwald (00:18:28 - 00:18:48)

Dann laufen halt ein paar Checks, wie zum Beispiel, wird unsere Applikation noch kompiliert, ist das YAML valide und so weiter und so fort und dann kann ein Repository-Owner sich die ganze Sache anschauen, macht dieser Change Sinn, sind diese Daten, die man da hinzufügt auch alle gut und alles super und dann drückt man einmal auf Merge und dann wird die ganze Sache in den Main-Branch überführt.

Wolfi Gassler (00:18:49 - 00:19:04)

Okay, und dann passiert die richtig große Magic, hast du mir erklärt. Vor allem dann sind wir erst in unserem German Tech Podcast Repository. Wie kommt denn das Ganze dann auf die Webseite, was passiert dann, was wird da denn alles angestoßen von deinem Zauberstab?

Andy Grunwald (00:19:04 - 00:20:16)

Dann wird es ein bisschen komplizierter in der Tat. Wenn ein neuer Commit ins Main Repository, in den Main Branch kommt, Dann kommt die erste Automation und die erste Automation nimmt sich das YAML, fragt noch ein paar andere Metadaten an einer externen API ab, dem sogenannten Podcast-Index. Und dieser Podcast-Index gibt mir zum Beispiel Informationen, wie viele Episoden hat denn dieser Podcast schon, wie ist denn die iTunes-ID für Apple-Podcasts oder vielleicht auch ein Bild. Dann lade ich diese ganzen Informationen runter, lade auch das Bild runter, mache da Achtung, jetzt kommt dein Lieblingsformat, ein JSON raus. Ja, das JSON ist dann ein generiertes JSON, was die YAML-Daten enthält und noch andere Daten, wie zum Beispiel ein sogenannter SLUG. Ein SLUG ist ein URL-kompatibler Name. Zum Beispiel bedeutet das aus engineering-kiosk formuliere ich dann einen SLUG, der nennt sich engineering-kiosk. Habt ihr vielleicht schon mal gesehen, wenn ihr irgendwie einen Blog habt oder ähnliches und ihr habt einen Titel dieser Und der Titel kommt in der URL vor, der ist dann aber URL-kompatibel und hat keine Sonderzeichen. Das nennt man zum Beispiel Slack. Sowas generiere ich dann, lade das Bild runter und das neu generierte JSON und das Bild committe ich dann wieder in den Mainbranch.

Wolfi Gassler (00:20:16 - 00:20:18)

In welcher Sprache machst du das?

Andy Grunwald (00:20:18 - 00:20:20)

Die Applikation ist jetzt in Golang geschrieben.

Wolfi Gassler (00:20:20 - 00:20:29)

Und da hast du dann irgendwie ein SDK von GitHub, um irgendwas zu commiten wieder? Oder wie läuft denn dieser commit im eigenen Repository ab?

Andy Grunwald (00:20:29 - 00:20:47)

Ich habe kein SDK von GitHub. Meine Golang-Applikation weiß nichts von GitHub. Wie läuft die Action ab? Ich merge diesen neuen Podcast von der externen Contributerin. Und die YAML-Datei landet im Main-Branch. Dann geht eine Action los. Diese Action klont sich mein aktuelles Repository.

Wolfi Gassler (00:20:47 - 00:20:51)

Wird das hier in der Action definiert oder machst du das selber wirklich mit dem Git-Klone?

Andy Grunwald (00:20:51 - 00:20:52)

Das wird in der Action definiert.

Wolfi Gassler (00:20:52 - 00:20:56)

Eine Action besteht aus... Also da gibt es eine Action-Git-Klone.

Andy Grunwald (00:20:56 - 00:21:10)

Ein GitHub-Action-Workflow-Job kann aus mehreren Subactions bestehen. Meine erste Subaction ist Checkout. Das bedeutet, ich mache einen Git-Klon automatisch von meinem eigenen Repository.

Wolfi Gassler (00:21:10 - 00:21:18)

Aber da musst du jetzt nichts großartig angeben oder mit irgendwelchen Keys oder so arbeiten. Das läuft alles vollautomatisch, wenn du so eine GitHub-Action hast.

Andy Grunwald (00:21:18 - 00:21:31)

Das läuft alles vollautomatisch. Authentifizierung wird von GitHub hintendran gemacht und eine GitHub Action oder ein GitHub Action Workflow hat immer Default-Zugriff auf das eigene Repository, read and write.

Wolfi Gassler (00:21:31 - 00:21:48)

Das heißt, es sind im Prinzip ein, zwei, drei Zeilen in dieser GitHub Workflow-Definition. Wenn man sich vorstellt, wenn man das selber bauen müsste, müsste man die gesamte Authentifizierung machen, mit Keys herum hantieren, irgendwo das laufen lassen, um überhaupt den ersten Schritt, dieses Klonen zu machen.

Andy Grunwald (00:21:48 - 00:22:21)

Ganz genau. Die erste Subaction nennt sich actions-checkout. Das bedeutet, klone mir das aktuelle Repository einmal runter auf disk. Und runter auf disk heißt hier auf irgendeinen Server, der von irgendwo von GitHub maintained wird in einem isolierten Environment. Dann installiere ich erstmal Go, Golang, die Applikation, die Programmiersprache. Als dritten Schritt kompiliere ich meine Go-Applikation. Du musst wissen, in dem German Tech Podcast sind nicht nur die YAML-Dateien, sondern da ist auch in einem Unter-Directory die Golang-Applikation.

Wolfi Gassler (00:22:21 - 00:22:26)

Und warum hast du die nicht schon kompiliert da drin als Binary?

Andy Grunwald (00:22:27 - 00:23:02)

Weil erstens müsste ich die dann nach jeder Code-Modifikation die kompilierte Binary wieder einchecken. Zweitens ist das ein Artefakt, was man immer kompilieren kann und warum sollte ich eine fertige Binary mit in den Source-Code einkompilieren? Du hast ja auch nicht ein Java-Repository und hast dann immer die letztkompilierte Version da irgendwie drin liegen. Drittens, blowt das das ganze Repository auf. Natürlich könnte ich das via GitFS oder Submodule einbinden oder ähnliches, aber ich sehe da keinen Vorteil drin. Ich kann ja auch dann am besten jede Zeit, wenn ich die GitHub Actions trigger, kann ich ja auch meine Golang-Applikation kompilieren. Das ist ja kein Overhead.

Wolfi Gassler (00:23:03 - 00:23:07)

Okay, du kompilierst dann die Go-Applikation, startest dann die Go-Applikation?

Andy Grunwald (00:23:07 - 00:24:37)

Genau, dann starte ich die Go-Applikation und diese Go-Applikation macht genau diesen YAML-to-JSON-Converter-Schritt. Das bedeutet, ich nehme mir das YAML, das was von einem Menschen geschrieben wurde, konvertiere das zu JSON. Als nächsten Schritt starte ich nochmal meine Golang-Applikation mit einem anderen Parameter. Die sagt mir, Lese bitte die ganzen JSON-Sachen und hol dir diese Metainformationen aus der Podcast-API, wie zum Beispiel das Bild, wie zum Beispiel die Apple-Podcast-ID und so weiter und so fort, und schreib das zurück in die JSON-Datei. Das bedeutet, an diesem Schritt habe ich also auf dem GitHub-Server ein dirty Git-Repository, weil ich habe es ja geklont und dann hat mein Go-Programm lokale Files modifiziert. Als nächsten Schritt nehme ich mir all diese JSON-Daten und rendere eine README raus, also einen Markdown-File. Warum mache ich das? Es ist zwar schön, dass wenn ich die Podcast-Informationen alle als JSON in dem Repository habe, aber wer schaut sich denn in seiner Freizeit JSON-Dokumente an? Also ich mache es nicht, vielleicht MongoDB-Entwickler oder sowas, weiß ich nicht, ich mache es auf keinen Fall. Deswegen habe ich mir gedacht, rendere ich eine schöne README raus mit einem schönen Bild, einer schönen Headline und so weiter und so fort. Das bedeutet, zu diesem Schritt in der GitHub Actions habe ich modifizierte JSON-Dateien, wahrscheinlich auch neue Dateien, nämlich die runtergeladenen Bilder von den Podcasts und eine modifizierte README. Und dann als vorletzten Schritt sage ich in der GitHub Actions, hey, deine lokalen Modifikationen, committe die bitte zurück in den Mainbranch.

Wolfi Gassler (00:24:37 - 00:24:41)

Das ist wieder eine eigene Subaction, die zur Verfügung steht.

Andy Grunwald (00:24:41 - 00:24:56)

Ganz genau. Das ist jetzt keine von GitHub, sondern von einem externen Contributor. Die kannst du dir dann einfach reinziehen. Die nennt sich Git Autocommit Action. Und da sagst du zum Beispiel, auf welchen Branch du committen möchtest, mit welcher Commit Message, welchem Commit User und so weiter und so fort.

Wolfi Gassler (00:24:57 - 00:25:02)

Und der ruft dann im Hintergrund einfach die Git-Command-Line auf wahrscheinlich, oder?

Andy Grunwald (00:25:02 - 00:25:12)

Müsste ich jetzt nachgucken, wie das unten drunter passiert. Ich habe jetzt keinen Code-Review gemacht. Schande auf mich, wie wir unsere MPM-Dependency-Folge gemacht haben. Müsste ich das jetzt eigentlich tun? Habe ich jetzt hier nicht gemacht.

Wolfi Gassler (00:25:12 - 00:25:25)

Folge 27 übrigens. Wir haben jetzt ziemlich viele Folgen zu verlinken in den Shownotes. Aber wer die noch nicht gehört hat, sind alles wirklich gute Episoden. Da könnt ihr fast einen Tag durch joggen gehen, wenn ihr die beim Joggen hört, die ganzen Folgen.

Andy Grunwald (00:25:26 - 00:25:40)

Dieser Workflow bedeutet natürlich auch, du merchst einen neuen Podcast in unser Repository und innerhalb von unter einer Minute taucht dein Repository schön gerendert in der README auf, völlig automatisch.

Wolfi Gassler (00:25:40 - 00:25:46)

Und wie viele E-Mails haben wir jetzt schon bekommen währenddessen? Mindestens zwei oder einmal für den merge und einmal für das neue commit.

Andy Grunwald (00:25:46 - 00:25:59)

Ja das liegt aber daran für den merge müsstest du eine e-mail bekommen haben für den automatischen commit nicht da müsstest du eine slack notification bekommen haben weil du ja auf diesem github slackbot stehst.

Wolfi Gassler (00:25:59 - 00:26:01)

Und warum bekomme ich keine e-mail?

Andy Grunwald (00:26:01 - 00:26:08)

Weil das einfach nur ein Commit in dem Repository ist. Da kommt es auf deine Notification Settings an, ob du dieses Repository watcht oder nicht. Und dann auf welchem Level du es benutzt.

Wolfi Gassler (00:26:08 - 00:26:17)

Ja, aber so wie normalerweise schon, glaube ich. Okay, verstehe mal. Zwei E-Mails. Jetzt hast du gesagt, das ist der vorletzte Schritt, dieses Commit. Was ist der letzte Schritt?

Andy Grunwald (00:26:17 - 00:26:46)

Ah, jetzt kommt der Engineering-Porn. Jetzt kommt der Engineering-Porn, das sag ich dir. Der letzte Schritt, und das müsst ihr alle einmal verstehen, wir haben zwei Repositories. Wir haben einmal einen Repository German Tech Podcast, das ist dieses alleinstehende Projekt, dass wir deutschsprachige Technologie-Podcasts listen wollen. Und dann haben wir ein anderes Repository, das ist unsere Homepage. Das ist also engineeringkiosk.dev, da, wo die ganze JavaScript-Magie passiert, mit Astro, diesem Meta-Framework.

Wolfi Gassler (00:26:46 - 00:27:06)

Wer sich da wirklich mal dafür interessiert, kann sich Episode 21 anhören über Static Site Generators und unsere Webseite, die der Andi da gebaut hat mit dem 0.0067AlphaPreAlpha irgendwas Astro Geschoss, das er da gefunden hat. Aber mittlerweile funktioniert das ja relativ gut, ich bin da schon sehr zufrieden dabei.

Andy Grunwald (00:27:07 - 00:27:16)

Alternativ könnt ihr auch mal rübergehen zur ProgrammierBar, ist ebenfalls ein weiterer Tech-Podcast. Die haben gerade ein Deep Dive zu Astro veröffentlicht, ich glaub, letzten Freitag.

Wolfi Gassler (00:27:16 - 00:27:24)

Moment, willst du sagen, unsere Folge war kein Deep Dive? Du bist da gar nicht so tief reingegangen, du als Backendler. Endlich mal Frontend geschraubt.

Andy Grunwald (00:27:24 - 00:28:11)

Ich bin ja immer noch ein Kacknoob, was Astro angeht. Der Herr, der bei der ProgrammierBar da zu Gast ist, der ist da Core-Contributor, der hat da deutlich mehr Ahnung als ich. Wie dem auch sei. Zwei Repositories. Einmal für den German Tech Podcast, einmal für die Webseite. Was passiert, wenn im German Tech Podcast neue Podcast-Daten generiert werden? Als letzten Schritt dieses Workflows triggere ich eine GitHub Action in unserem Homepage-Repository. Und zwar kannst du bei GitHub Actions sagen, Repository Dispatch und kannst sagen, hier ist mein Event-Type. Und dieser Event-Type ist ein Custom-String, den du selbst festlegen kannst. Ich hab jetzt einfach mal Podcast-List-Update genannt. Und da kannst du noch Daten ranpacken, wie zum Beispiel Git-Comment-Messages oder ähnliches. Das ist halt ein Payload. Stell dir vor, du machst einen Webhook.

Wolfi Gassler (00:28:11 - 00:28:29)

Also das ist wirklich ein Event-Bus zwischen den Repositories sozusagen. Und kann es irgendein Repository sein, oder muss das in der gleichen Organization sein? Wie läuft das ab? Oder auch von der Authentifizierung, muss das ja irgendwie Sicherheitsmaßnahmen geben? Ich kann nicht irgendwohin Events senden.

Andy Grunwald (00:28:30 - 00:28:54)

Also prinzipiell kann das jedes Repository sein, was du möchtest, aber du musst dem Repository-Dispatch-Event schon noch einen Personal Access Token von GitHub mitreichen, der dann Schreibzugriff auf das andere Repository hat. Das bedeutet, ich kann jetzt von meinem Space nicht einfach eine GitHub-Action in deinem Repository, in deiner Organisation pushen, ohne dass ich da keinen Schreibtagszugriff drauf habe.

Wolfi Gassler (00:28:55 - 00:29:04)

Jetzt habe ich gerade mal reingeschaut in unsere Definition. Da steht natürlich kein Plaintext-Token drinnen. Wie läuft das mit dem Token-Management?

Andy Grunwald (00:29:04 - 00:29:50)

GitHub selbst hat eine Funktion, die nennt sich GitHub Secrets. Und in GitHub Secrets kannst du entweder auf Organisationsbasis oder auf Repository-Basis Passwörter, Authentifizierungstokens oder alles halt das, was du Secret halten möchtest, eintragen. und kannst das dann mit einer Variable Secrets.denNamen, den du vergeben hast, in deiner GitHub Action nutzen. Ein Klassiker dafür ist zum Beispiel API-Keys. Ich habe vorhin gesagt, wir sprechen die Podcast Index API an. Dafür brauche ich einen API-Key. Diesen habe ich mir auf der Webseite von der Podcast Index API geholt. habe den in GitHub-Secrets eingepackt und greife in meiner GitHub-Action auf diesen Podcast-Index-API-Key zu und in den GitHub-Actions-Logs wird er dann mit Sternchen, Sternchen, Sternchen markiert.

Wolfi Gassler (00:29:51 - 00:29:55)

Und wie kann ich darauf zugreifen? Ist es eine Environment-Variable?

Andy Grunwald (00:29:55 - 00:29:57)

Es ist eine vordefinierte Variable.

Wolfi Gassler (00:29:57 - 00:30:13)

Aber das muss ich in der Workflow-Definition dann definieren, dass ich dieses Passwort XY oder von der API zum Beispiel, vom Podcast-Index, dass ich diese Daten jetzt verwenden will bei diesem speziellen Bild und das zur Verfügung stelle über eine Environment-Variable?

Andy Grunwald (00:30:13 - 00:30:25)

Es ist keine Environment-Variable, sondern es ist eine Variable, die dir in dem Workflow zur Verfügung steht, und die greifst du dann mit Dollar, geschweifte Klammer, geschweifte Klammer, Secrets und so weiter und so fort, greifst du dann darauf zu genau.

Wolfi Gassler (00:30:25 - 00:30:31)

Ist es keine Environment-Variable, wenn sie einfach in Pesh als Variable zur Verfügung steht? Gibt's da einen Unterschied?

Andy Grunwald (00:30:31 - 00:30:39)

Ja, also entweder hast du eine Variable in deinem Workflow, die in dem Workflow zur Verfügung ist, oder du hast eine Environment-Variable, auf die du dann explizit zugreifen musst.

Wolfi Gassler (00:30:40 - 00:30:47)

Aber wenn du jetzt sagst, Variable im Workflow, das heißt in der Workflow-Dokumentation oder in der Definition?

Andy Grunwald (00:30:47 - 00:30:49)

In der Workflow-Definition, genau.

Wolfi Gassler (00:30:49 - 00:30:56)

Und wie bekommst du dann in der Go-Applikation? Musst du das dann irgendwie übergeben als Parameter?

Andy Grunwald (00:30:56 - 00:31:07)

Ja, das kommt jetzt ganz natürlich darauf an, wie du die Applikation geschrieben hast. Ich habe jetzt hier einfach ein Command-Line-Argument gemacht. Ich habe "--ipi"-Key und dann habe ich das Secret als Command-Line-Argument übergeben.

Wolfi Gassler (00:31:08 - 00:31:24)

Okay, das macht es natürlich sicherer, weil du dann keine Environment-Variablen hast, weil sonst könnten dir diese Actions zum Beispiel auf deine Environment-Variablen zugreifen. Oder können sie natürlich, aber wenn du dort die API-Daten usw. drinnen hättest, wäre das ja ein großes Sicherheitsrisiko, wenn du fremden Code verwendest.

Andy Grunwald (00:31:24 - 00:31:37)

Lassen wir mal die Kirche im Dorf. Wir exekuten hier etwas, unseren Code, auf fremder Infrastruktur. Und du erzählst mir jetzt, dass GitHub auf irgendwelche Environment-Variablen zugreifen kann. Also ich glaube, wenn du GitHub in der Sache nicht vertraust, dann solltest du gegebenenfalls deinen eigenen Git-Server hosten.

Wolfi Gassler (00:31:38 - 00:32:04)

Nein, nein, mir geht es nicht um GitHub, sondern diese Subactions, die ich verwende, die können ja auch von irgendwelchen Usern sein. Du hast ja auch gesagt, du verwendest jetzt irgend so ein Git-Commit, Auto-Commit-Ding von irgendwem und wenn der natürlich dann da Code einschleust, das haben wir eben in unserer NPM-Folge, in der Folge 27 auch besprochen, und du hast alle API-Keys in den Environment-Variablen, dann hätten die natürlich Vollzugriff. Die können das ja auch dann irgendwo hinsenden im schlimmsten Falle.

Andy Grunwald (00:32:04 - 00:32:31)

Das ist eigentlich, diese Subactions sind auch nur fremde Dependencies, fremder Code, den ich mir reinhole. Das ist genau das gleiche Sicherheitsrisiko mit allem Drum und Dran, Typo-Squatting, ich sende Credentials an irgendwas, an einen externen Server und so weiter. All das, was wir in dieser NPM-Dependency-Folge haben und was nicht NPM-spezifisch ist, passiert hier genauso. Also das ist alles genau das Gleiche, weil das ist fremder Code, den ich in meinen Code einbaue, und dann können die natürlich auch da alles machen, logisch.

Wolfi Gassler (00:32:32 - 00:32:46)

Aber es ist schon ein bisschen sicherer, wenn ich das als Parameter zum Beispiel übergebe und das Ganze im Aufruf ersetzt wird vom GitHub, weil dann nicht automatisch alle Actions auf alle Daten zugreifen können. Dann kann man das auch schon ein bisschen fein granularer bauen.

Andy Grunwald (00:32:47 - 00:34:14)

Theoretisch würde ich sagen, ja, kommt aber auf die Implementierung von GitHub-Actions auf GitHub-Seite drauf an, ob die einzelnen Actions selbst noch mal isoliert sind oder nicht. Das kann ich dir nicht sagen, weil ich den Code nicht kenne. Aber ich hoffe mal, dass die einzelnen Actions isoliert voneinander sind, weil die einzelnen Actions können auch nur über gewisse Interfaces miteinander sprechen. Jede Action, jeder Workflow-Step kann sogenannte Outputs definieren. Das sind also Werte, die du in einer nachfolgenden Action von der vorherigen Action nutzen kannst. Wie zum Beispiel, ich kann jetzt eine GitHub-Action schreiben und als Output gebe ich den Exit-Code mit raus. Und bei Exit-Code 0 ist alles super, bei Exit-Code 1 war die Datei nicht verfügbar, bei Exit-Code 2 war der Remote-Server nicht verfügbar und so weiter und so fort. Und auf Basis des Exit-Codes von meiner Action möchtest du vielleicht in der nächsten Action eine Ausführung machen. Immer nur wenn der Remote-Server nicht da ist, möchtest du einen Retry machen. Immer wenn die lokale Datei nicht da ist, möchtest du einen Bug-Report eröffnen. Und somit kannst du dann in der nachfolgenden Action, ähnlich wie du auf die Secrets mit einer Variablen zugreifst, kannst du über Output Punkt dann auf die definierten Outputs zugreifen. Das würde ich als eindeutige Schnittstelle zwischen zwei GitHub Actions beschreiben. Und deswegen hoffe ich mal, dass GitHub selbst die Implementierung so gebaut hat, dass die Ausführung einzelner Actions isoliert ist. Aber das geht jetzt hier zu weit, weil das ist Mutmaßung. Wir kennen den Code von GitHub nicht.

Wolfi Gassler (00:34:14 - 00:35:04)

Wer sich der auskennt, vielleicht eine kurze Twitter. Message, um uns da aufzuklären. Mein Guess wäre, es wird nicht separiert ausgeführt, sonst müsst ihr ja alle Sachen wieder installieren und so weiter. Aber ich finde schon mal gut, dass nicht alles in Environment-Variablen gesteckt wird, weil es ist schon ein großes Sicherheitsrisiko. Und wenn man so hört, viele Angriffe passieren genau darüber. Man bekommt halt Zugriff irgendwo in irgendeiner isolierten Docker-Umgebung, liest einmal die Environment-Variablen aus und bekommt da schon 10 Keys zu Datenbanken, zu verschiedensten Services. Also das ist schon auch ein großes Sicherheitsrisiko. Aber gehen wir mal zurück zu den Events. Du sendest jetzt ein Event zu einem anderen Repository, in dem Fall unsere Webseite, wo Astro draufläuft oder es läuft nicht, aber es wird halt verwendet beim Build. Was passiert dann auf der anderen Seite? Wer nimmt dieses Event überhaupt entgegen?

Andy Grunwald (00:35:04 - 00:36:54)

Das Event wird von einer anderen GitHub Action, von einem anderen GitHub Action Workflow entgegengenommen. Und zwar habe ich ja gesagt, diese Automation Workflow Engine kann auf sogenannte Trigger reagieren. Cronjob, manueller Button oder halt auf Repository Dispatch Events. Und dort habe ich ein Workflow definiert, das sagt, wenn ein Event an dieses Repository kommt mit dem Typ Podcast List Update, dann Trigger bitte diesen Workflow. Und dieser Workflow Der klont jetzt ebenfalls wieder das lokale Repository. Und Achtung, du bist ja jetzt in einem anderen Kontext. Das lokale Repository hier ist dann die Homepage. In dem Repository von der Homepage liegt ein Python-Skript. Das bedeutet, ich installiere hier nicht Go, ich installiere hier dann Python. Installiere mir die ganzen Python-Dependencies, die ich brauche. und rufe das Python-Skript auf, was mir sagt, hey, liebes Python-Skript, klon doch mal das German Tech Podcast Repository lokal in ein lokales temp-directory. Kopier mir die JSON-Dateien daraus und merge diese einzelnen JSON-Dateien, die ja vom German Tech Podcast generiert wurden, in ein JSON-File. Kopier mir die Bilder daraus, resize die ein bisschen und pack die bitte in den Public Folder. Und dann hab ich ja wieder ein dirty Git-Repository von der Webpage, da ich ja Bilder und Dateien rüber kopiert habe und Dateien modifiziert habe. Und das committe ich dann wieder in die Webpage. Und auf Basis des neuen Commits in der Webpage wird Netlify getriggert, was dann wiederum ein Astro-Build triggert. was dann wiederum ein Deployment nach engineeringkiosk.dev triggert. Das bedeutet, wir haben jetzt einen kompletten Workflow über zwei Repositories. Wenn du den Schweizer Podcast hinzufügst und ich merge den, dann hast du weniger als drei Minuten mit Bild, mit allen Metainformationen, alles live auf unserer Webseite.

Wolfi Gassler (00:36:55 - 00:37:01)

Das heißt, es geht von Go zu Python und am Ende zu JavaScript. Du wechselst auch deine Sprachen wie Unterhosen, oder?

Andy Grunwald (00:37:01 - 00:37:03)

Das ist korrekt, das hat aber alles historische Gründe.

Wolfi Gassler (00:37:04 - 00:37:10)

Das ist immer die Standard Antwort, hat historische Gründe. Das heißt, du bist geboren zu Politiker, Andi.

Andy Grunwald (00:37:10 - 00:37:43)

Manche Leute würden sagen, das sind jetzt technische Schulden. Ich würde sagen, es ist Pragmatismus und das funktioniert. In der Webpage, in der Homepage hab ich halt angefangen, einfach ein paar Sachen mit Python auszuführen, weil am Anfang war es wirklich nur Check dies, Check das, so ganz Basissachen. Das sind inzwischen drei oder vier größere Python-Skripte, die da am Start sind. Als ich dann das neue Projekt German Tech Podcast begonnen habe, wurde es dann mit Golang gemacht, weil ich dort dann einfach ein bisschen schneller war. Ja, was soll ich dazu sagen? Das ist jetzt halt einfach so. Funktioniert aber, wie du siehst.

Wolfi Gassler (00:37:44 - 00:38:25)

Und zwar sehr gut und am Ende wird eben diese Webpage auf unserer Webseite zu den deutschsprachigen Tech-Podcasts, also ihr könnt gerne mal auf unsere Webseite gehen, engineeringkiosk.dev und dann im Menü auf deutschsprachige Tech-Podcasts klicken und dann bekommt man da eben eine schöne gerenderte Liste von den ganzen Podcasts, inklusive den Metadaten, wie viele Episoden so ein Podcast hat, wann die letzte Episode veröffentlicht wurde. Und das Ganze auch noch schön markiert mit einem Statuspunkt, rot, gelb, grün, wie aktiv die Podcasts aktuell sind oder wie lange sie schon eben inaktiv sind. Dann werden sie nach einer gewissen Zeit rot.

Andy Grunwald (00:38:25 - 00:39:10)

Und genau diese GitHub-Actions, die ich gerade besprochen hab, die läuft auch als Scroll-Job. Weil hoffentlich sind die Podcast natürlich aktiv und hoffentlich bringen sie in einem regulären Intervall eine neue Episode raus. Das bedeutet, ich triggere diesen Podcast Data Update Workflow einmal die Woche komplett automatisch und somit kann sich natürlich auch diese Ampel, die du gerade erwähnt hast, jede Woche ändern. Wenn seit über sechs Monaten keine Episode mehr veröffentlicht wurde, markieren wir diesen Podcast als Inaktiv mit einer roten Ampel. Wurde in den letzten zwei Monaten eine neue Episode veröffentlicht, ist er grün. Und alles was zwischen zwei und sechs Monaten ist, ist eine Warnung. Wie man sagt, so schön im deutschen Straßenverkehrsgesetz. Und zwar ist das gelb. Achtung, vielleicht sollte man hier mal bremsen.

Wolfi Gassler (00:39:10 - 00:39:18)

Oder vielleicht eher aufs Gas steigen in dem Fall. Eine kleine Info oder ein kleiner Push an die Hosts, wieder mal was zu publizieren.

Andy Grunwald (00:39:18 - 00:39:47)

Vielleicht, vielleicht, genau. Neben diesen Metadaten, die wir aus APIs bekommen, haben wir auch alle Podcast-Hosts angefragt, um zum Beispiel Metainformationen, die Weekly Average Downloads zu kriegen. Nicht alle haben reagiert. Warten wir mal, vielleicht kommt da ja noch was. Wie dem auch sei, das ist auf jeden Fall ein Use Case, wie ich mir hoffentlich mein Leben als Softwareentwickler im Engineering-Kiosk-Seitprojekt erleichtere.

Wolfi Gassler (00:39:47 - 00:40:08)

Jetzt kennst du ja auch die ganze Welt und wir haben da ja viel gemacht mit Jenkins und Co., wie man das halt früher so gemacht hat. Wenn du das jetzt vergleichst, wirst du es auch sehen im professionellen Umfeld, dass man das durchaus verwenden kann oder hat da schon Jenkins noch irgendwelche Vorteile? Wie ist denn da deine Meinung dazu, deine Beurteilung zu dem ganzen Bereich?

Andy Grunwald (00:40:08 - 00:41:33)

Kann man GitHub Actions im professionellen Umfeld verwenden? Ja, 100%. Warum ist das eine tolle Geschichte? Es ist super günstig. Alle Workflow Definitions sind standardmäßig als Code im Repository hinterlegt. Das bedeutet, du hast deine CI, CD und deine Automation Workflows direkt in deinem Quellcode. Die Definition von diesen Actions und Workflows ist sehr, sehr einfach. Sie passiert innerhalb des YAML-Formats. Ich würde fast sagen, dass jeder Entwickler und jede Entwicklerin das super einfach schreiben kann. Und es ist ein, ich würde mal sagen, Engineering-focust Workflow. Du holst dir externe Dependencies rein, kannst deine eigenen Actions schreiben und niemand muss sich um die Server und Infrastruktur dahinter kümmern. Weitergehend kannst du GitHub Actions auf mehreren Betriebssystemen von Haus aus führen. Linux. Du kannst Base-Images definieren. Welche Ubuntu-Version. Du kannst die Dinger auf Mac, OS X oder Windows laufen lassen. Du kannst das als Matrix laufen lassen. Führe bitte meine Unit-Tests auf allen drei Betriebssystemen Windows, Mac, Linux aus. Und dann bitte noch zu drei Golang-Versionen. Das macht er alles automatisch. Einfach mit einer Zeile. Das ist schon alles sehr, sehr, sehr bequem. Und super einfach von Entwicklern zu steuern. Hat jetzt Jenkins noch eine Daseinsberechtigung? Ja, hundertprozentig. Jenkins ist auch ein super System. Super viele Leute werden sagen, bar Jenkins. Der Punkt ist einfach nur, Jenkins ist unglaublich erwachsen. Ich kenne nichts, was man nicht mit Jenkins machen kann.

Wolfi Gassler (00:41:33 - 00:41:38)

Hast du irgendwas, was man mit GitHub Actions nicht machen kann, mit Jenkins aber schon?

Andy Grunwald (00:41:38 - 00:42:05)

Ja, zum Beispiel, wenn du die GitHub Actions auf github.com in der Cloud-Version nutzt, kannst du zum Beispiel kein Deployment auf lokale Server in deinem eigenen Netzwerk machen, was du mit Jenkins, mit einem selbst gehosteten Jenkins schon kannst. Du kommst an lokale Infrastruktur einfach nicht ran. Das bedeutet, hast du einen eigenen Package-Repository für deine eigenen NPMs, für deine NPM-Pakete, kannst du keinen NPM-Install aus GitHub Actions in github.com machen.

Wolfi Gassler (00:42:05 - 00:42:14)

Kannst du da irgendwie eigene Runner oder sowas machen? Gibt's ja relativ oft bei so Systemen, dass man irgendwie einen internen Runner hat, der dann Zugriff bekommt. Ist das möglich mit GitHub?

Andy Grunwald (00:42:14 - 00:44:45)

Das kannst du machen. Du kannst eigene GitHub-Runner definieren. Das bedeutet aber auch, du setzt eigene VMs auf oder eigene Server, hookst sie ab in deiner GitHub-Action, in deiner GitHub-Organisation und so weiter und so fort. Und dann geht's natürlich schon wieder. Man muss aber sagen, das Hosten von eigenen Runnern ist nicht unkompliziert, die Isolation ist nicht unkompliziert. Wir haben das bei Trivago mal gemacht und man muss da schon ein bisschen Arbeit investieren, um das ordentlich ans Fliegen zu kriegen, weil du musst dich natürlich dann auch um die komplette Skalierung von diesen Runnern kümmern. Das bedeutet, hast du mal 30 Engineers, 40 Engineers, die richtig durchballern, dann starten natürlich auch relativ viel GitHub Actions. Und das muss deine Infrastruktur abkannen. Das bedeutet, theoretisch, nicht nur theoretisch, sondern auch praktisch, wir haben das nämlich bei Trivago genauso erlebt, die Runner kommen auch an ihre Grenzen. Das bedeutet, hast du deine Runner in der Google Cloud oder in Amazon, musst du auch zusehen, dass diese Runner auch autoskalieren. Auf Basis deiner GitHub Action Performance. Du kannst natürlich ein paar Hacks machen. Du kannst sagen, okay, du betreibst deine kompletten GitHub-Actions auf GitHub.com und ein Workflow-Step ist, sende einen Webhook an einen Public Endpoint. Und dieser Public Endpoint hat dann einen API-Key. Das bedeutet, dieser Public Endpoint ist dann irgendeine Code-Logik auf deiner Infrastruktur, Und wenn ein Request mit einem bestimmten Passwort oder API kommt, dann führe ein Deployment aus. Solche Baustellen kannst du schon machen, dann bist du aber schon wieder in dem Feld, wo du sehr viel eigene Infrastruktur, sehr viel eigenen Code, sehr viel Custom-Logik baust. Und dann ist die Frage, willst du das? Ist die Firma groß genug, die das auch maintainen kann? Oder macht es nicht einfach Sinn, stellst du einfach ein Jenkins dahin. Weil auch Jenkins supportet natürlich inzwischen die Workflow Definition per Code, nennt sich Jenkinsfile. Ich weiß gerade gar nicht, ob das immer noch in Groovy definiert wird, aber mich würde nicht wundern, wenn es irgendwo ein Plugin gibt, dass du deine Jenkinsfile auch irgendwie in YAML definieren kannst. Aber Jenkins ist immer so, bei super vielen Leuten wird da so, bar nee, kein Jenkins. Und Jenkins kann auch Schmerz sein, ihn zu maintainen. Besonders, wenn man sehr viele Jobs hat. Besonders, wenn man sehr viele externe Plugins drin hat. Weil auch das muss geupdatet werden, Plugins brechen und so weiter. Und wenn man besonders die Unit- oder Integration-Tests auch auf verschiedenen Betriebssystemen ausführen kann. Denn jeder weiß, was für ein Pain es ist, Mac-Server hinzustellen. Wie viele Server-Offerings kennst du von Apple?

Wolfi Gassler (00:44:45 - 00:44:49)

Gute Frage. Gibt sowas überhaupt von Apple selber? Wahrscheinlich gar nichts, oder?

Andy Grunwald (00:44:49 - 00:45:26)

Meines Wissens nach gibt es von Apple kein Server Offering und was ich wohl weiß und das haben wir auch schon gemacht, du hookst ab irgendwelche Mac Minis ins Datacenter oder in irgendwelchen Räumen von deinem Büro und lässt halt da drauf die iOS Apps kompilieren oder deine Applikation muss auf Mac laufen. Und das ist halt echt scheiße. Das willst du halt einfach nicht maintainen. Weil die Dinger passen nicht ordentlich ins Rack. Dann hast du überall so Tische da rumstehen, da stehen die Dinger drauf, gesteckt noch. Das ist alles Kacke. Und so was möchtest du eigentlich nicht machen. Du möchtest nicht deine eigene Mac-Farm hosten. Wenn du das möchtest, dann wünsch ich dir viel Spaß.

Wolfi Gassler (00:45:26 - 00:45:29)

Aber so was gibt's sicher virtualisiert angeboten irgendwo, oder, Schätzchen?

Andy Grunwald (00:45:29 - 00:45:50)

Ja, GitHub Actions kann das, CircleCI kann das. Wie die das hinten drunter machen, weiß ich jetzt gerade nicht. Aber ja, es gibt auch dann Hackintoshs, wo du mit irgendwelchen Donglen so was emulieren kannst, wo du macOS dann auf eigener Hardware fahren kannst und nicht auf Mac-Hardware. Gibt's bestimmt alles irgendwie. Und jetzt die nächste Frage, willst du das im professionellen Umfeld haben?

Wolfi Gassler (00:45:50 - 00:45:54)

Ja, solange es jemand anderer macht, bin ich da schon okay damit.

Andy Grunwald (00:45:54 - 00:46:21)

Auf jeden Fall kannst du das alles relativ einfach mit GitHub Actions machen. Preise sind völlig moderat. Und wenn ihr jetzt sagt, hey, Andi, was erzählst du mir denn da? Das ist ja alles nur im professionellen Umfeld, im Firmenumfeld. Nein, ist es nicht. Und zwar auf GitHub könnt ihr private Repositories, sind umsonst, und somit habt ihr auch ein freies Kontingent an GitHub Actions. Ich mach sehr viel mit GitHub Actions, und ich muss zugeben, an dieses freie Kontingent bin ich noch nie ans Limit gestoßen. und auch wenn, dann kostet eine Minute ein paar Cent.

Wolfi Gassler (00:46:21 - 00:46:30)

Das heißt man muss da nicht automatisch dann irgendwie upgraden zu einem anderen Plan oder so, wo man dann irgendwie sehr viel zahlen muss, bevor man da überhaupt mal die einzelnen Minuten bezahlen kann.

Andy Grunwald (00:46:30 - 00:46:31)

Completed paper use.

Wolfi Gassler (00:46:32 - 00:46:51)

Jetzt hätte ich noch eine andere Frage und Achtung, jetzt kommt die perfekte Überleitung für eine Werbung, für einen guten Kollegen von uns. Ihr habt gestern, glaube ich, war das, ein E-Mail bekommen von einem dieser Automations, dass bei dir ein Linkedin-Link von deinem Profil nicht funktioniert von Leetchi. Erklär mal, was das war.

Andy Grunwald (00:46:51 - 00:47:20)

Ich habe einen GitHub Actions Workflow eingebaut, um unsere Webseite zu verbessern. Die Grundidee ist, unsere Suchmaschinenoptimierung zu verbessern. Und immer wenn Google auf unsere Website kommt und tote Links findet, was halt immer passieren kann, ist das doof für die Reputation unserer Website. Deswegen habe ich mir gedacht, warum automatisierst du nicht einfach das Link-Checking? Also habe ich ein GitHub-Automation-Workflow gebaut, was ein Open-Source-Projekt namens Litchi nutzt. Viele Grüße an den Matthias.

Wolfi Gassler (00:47:21 - 00:47:29)

Verlinken wir gerne, ist ein Open-Source-Projekt. Wir bekommen auch kein Geld leider von Matthias. Wobei, vielleicht sollte man das mal einfordern von Matthias, wenn wir da schon Werbung machen.

Andy Grunwald (00:47:29 - 00:47:49)

Litchi, dem kannst du eine Datei geben, eine Webseite oder ähnliches und er crawlt das dann und guckt nach, welche Links sind denn tot, welche funktionieren noch und gibt dir dann ein Report raus. Und was ich gedacht habe, funktioniert ganz gut. Ich lasse Litchi einfach einmal in der Woche laufen und bei jedem kaputten Link macht er mir ein offenes Issue auf.

Wolfi Gassler (00:47:49 - 00:48:00)

Hast du da jetzt irgendwie Litchi, also das Ganze selber schreiben müssen oder gibt es da schon irgendwie eine Action von Litchi? Oder müssen wir da eben Matthias mal treten, dass er da eine Action bereitstellt?

Andy Grunwald (00:48:01 - 00:48:10)

Litchi selbst ist in Rust geschrieben und ist ein Command-Line-Tool und auf Litchi hat Matthias dann bereits eine fertige GitHub-Action gebaut. Und das ist natürlich super und die konnte ich dann einfach reinbinden.

Wolfi Gassler (00:48:10 - 00:48:29)

Also man macht da Copy-Paste von drei Zeilen und hat dann den wirklich sehr exklusiven Link-Checker übrigens, der wirklich eben probiert mal einen Link zu checken von Twitter oder von LinkedIn, ist gar nicht so einfach, weil die natürlich da Mechanismen haben, Bot-Detection und solche Sachen. Und das war's dann, oder? Drei Zeilen einbinden.

Andy Grunwald (00:48:29 - 00:48:50)

Genau, drei oder vier Zeilen, um die Link-Check-Action einzubauen, Litchi-Action. Und Litchi hat dann auch einen sogenannten Output. Und als nächste Workflow-Action habe ich dann gesagt, okay, Create Issue. Wenn der Output das und das ist, dann erstelle bitte automatisch ein GitHub-Issue in meinem Propositorium. Das hat dann leider dazu geführt, dass.

Wolfi Gassler (00:48:50 - 00:48:52)

Ich noch mehr E-Mails bekommen habe. Ich weiß.

Andy Grunwald (00:48:52 - 00:49:33)

Da sind ein paar mehr Issues erstellt worden. Das ist richtig. Und dann habe ich mal reingeguckt, was da eigentlich passiert ist. Und zwar haben Wolfgang und ich auf der Engineering-Kiosk-Webseite unsere LinkedIn-Profile verlinkt. Und LinkedIn, wenn da mal ein Link abgefragt wird, senden die einen HTTP-Statuscode 999. Es gibt keinen HTTP-Statuscode 999. Also LinkedIn macht da sehr wirre Sachen. Warum machen die wirre Sachen? Natürlich wollen die verhindern, dass du öffentliche Profile und CVs und so weiter crawls und dann Daten klauen machst, weil das kann natürlich dann alles irgendwie im Security-Bereich sehr böse werden, wenn du Identitätstäuschungen machst oder ähnliches.

Wolfi Gassler (00:49:33 - 00:49:37)

Oder einfach nur deren Daten einfach irgendwie abgreifst. Wollen die natürlich auch nicht.

Andy Grunwald (00:49:37 - 00:49:49)

Auf jeden Fall sagt Litchi dann, das ist hier irgendwie nicht 200, das ist kein HTTP 300, das ist kein HTTP 400, das ist kein 500, das ist irgendwas, was halt völlig wir ist.

Wolfi Gassler (00:49:49 - 00:50:36)

Aber da würde jetzt Matthias sagen, du kannst gerne ein Pull-Request schreiben, weil es ist sehr modular und er hatte eben schon für extrem viele Plattformen, auch mit anderen Leuten zusammen, die da viele Pull-Requests liefern, eben solche speziellen Module geschrieben für Twitter zum Beispiel, weil Twitter macht genau dasselbe oder auch andere große Plattformen, die liefern dir alle irgendwelche Status Codes aus, obwohl das vielleicht existieren würde. Und das ist dann eben gar nicht mehr so leicht, wirklich Links zu checken durch diese ganzen Sicherheitsmechanismen, die die großen Plattformen betreiben. Also du kannst es für LinkedIn sicher nachliefern, da Matthias hat eine große Freude. Und dann habe ich gesehen, würde das auch automatisch auf deinem Profil landen. Ich war nämlich gerade auf deinem GitHub-Profil. Und da hast du drinstehen, latest pull requests I published. Jetzt ist meine Vermutung mal, du machst das auch mit GitHub Actions, hoffe ich.

Andy Grunwald (00:50:37 - 00:50:41)

Ich komme immer wieder zu der Frage, was ist dir wichtiger? Disziplin?

Wolfi Gassler (00:50:41 - 00:51:02)

Oder Faulheit? Fällst du jetzt da in das Faulheit oder ins Disziplin rein? Weil man würde ja meinen, du bist sehr diszipliniert, weil da steht ja wirklich check out what i'm currently working on und dann steht da engineering kiosk one day ago, vdf two weeks ago, das kannst du ja nicht händisch pflegen oder? So diszipliniert bist du nicht.

Andy Grunwald (00:51:02 - 00:51:44)

Das ist korrekt. Ich bin zwar sehr diszipliniert, aber ich nur in der Organisation, dennoch, Für blöde Arbeit, die automatisier ich mir weg. Und so mache ich das zum Beispiel in meinem GitHub-Profil. In meinem GitHub-Profil kann man inzwischen einen Markdown-File hinterlegen und dieses Markdown-File wird auf der Startseite von deinem GitHub-Profil angezeigt. Und was man mit diesem Markdown-File dann macht, das ist dir ja überlassen. Also was habe ich gemacht? Ich habe da eine GitHub-Action hingepackt. Die GitHub-Action gibt's schon fertig, die wurde von einem anderen Open-Source-Entwickler entwickelt. Hab dann ein Readme-Template dahingelegt und diese GitHub-Action crawlt die GitHub-API nach meinen letzten Contributions. Oder nach meinen letzten geöffneten Pull-Requests.

Wolfi Gassler (00:51:44 - 00:51:49)

Das hast du nicht selber geschrieben, oder? Da gibt's auch schon Tools, die das machen, so Actions.

Andy Grunwald (00:51:49 - 00:52:28)

Da gibt's was Fertiges von dem GitHub-Contributor Müsli. Sehr, sehr fähiger Mensch. Auf jeden Fall wird da, ich glaube einmal pro Tag, läuft da ein automatischer Cron-Job, also eine GitHub Actions, die einen Cron-Träger hat und nimmt sich die letzten Pull-Requests, die ich gemacht habe, die letzten Issues, die ich aufgemacht habe. Dabei crawle ich noch den RSS-Feed von meinem Blog, publische das und da kannst du sehen, woran ich gerade so arbeite. Ist natürlich jetzt nicht nur relevant für dich, ob du entscheidest, mir zum Beispiel zu folgen, sondern auch vielleicht für zukünftige Arbeitgeber. Von mir aus auch für irgendwelche Recruiter oder oder oder.

Wolfi Gassler (00:52:28 - 00:52:35)

Die Recruiter denken dann alle, du bist zu fleißig und gehst da täglich rein und updatest das eine ganzen one day ago, two days ago.

Andy Grunwald (00:52:36 - 00:52:47)

Wie sagte Bill Gates immer so schön, er würde lieber nicht sehr intelligente Menschen einstellen, sondern nur sehr faule, weil die einfach einen Weg finden, wie sie die Arbeit schneller machen können. Wenn die Rekrute das denken, finde ich das sehr schön.

Wolfi Gassler (00:52:48 - 00:53:35)

Oh, dieses Zitat kenne ich gar nicht. Bin gespannt, ob ihm das nur zugeschrieben wird oder ob er das wirklich mal gesagt hat. Das müssen wir noch recherchieren. Wer sich auf jeden Fall interessiert für diese Dinge, kann die ja auch, weil die in einem GitHub-Repository einfach liegen, direkt anschauen. Da gibt es immer einen Folder, der .github heißt und dann Workflows und dort drinnen liegen dann klarerweise wieder YAML-Dateien, wo diese Workflows definiert sind und man kann sich das auch einfach mal alles auschecken und anschauen und mal da in den Code reinschauen, was der Andi da fabriziert hat oder eben was dann auch die Actions dementsprechend machen, ist alles sehr offen. Und darum habe ich auch am Anfang erwähnt, ihr habt bisher recht viel Copy-Paste gemacht, weil man halt einfach viele Infos bekommt und sieht, wie das andere macht. Man kann sich das einfach mal kopieren und dann adaptieren oder editieren, was man braucht und dementsprechend den Workflow anpassen.

Andy Grunwald (00:53:36 - 00:54:58)

Innerhalb könnt ihr mit GitHub Actions machen, was ihr wollt. Und mit was ihr wollt meine ich wirklich alles, was mit Code machbar ist, könnt ihr in irgendeiner Art und Weise machen. Innerhalb von Trivago haben wir zum Beispiel eine Automation gebaut, dass, wenn ein bestimmtes GitHub-Repository ein spezifisches Label bekommen hat, nennt sich auf GitHub Topics, dann ist die Automation losgetreten und hat einer kompletten Usergruppe Schreibrechte auf dieses Repository gegeben. Das haben wir gemacht, um Cross-Team-Contributions zu enablen. Nennt sich unter anderem auch Inner-Source. Die Ausführung von Open-Source-Back des Best-Practices innerhalb einer geschlossenen Organisation, weil wir wollten unter anderem, dass Bug-Fixes und Features nicht immer über den Produktmanager oder Product-Owner gehen, sondern Vielleicht setzt sich Team A einfach mal hin, checkt sich das Repo von Team B aus und macht einfach ein Pull-Request, um den Bug zu fixen. Das war so die Hoffnung und in sehr sehr guten Kulturen ist das auch so. Da geht es natürlich sehr flott mit Product Development und sowas haben wir dann zum Beispiel gemacht, ohne halt diesen langen Weg von Oh, kann ich da Schreibrechte haben? Und mach mal ein Access Management Ticket oder Write Management Ticket oder wie das auch immer heißt. Da haben wir den Engineers einfach gesagt, hör mal, könnt ihr mal einfach das Inner Source Label an das Repository packen? Und flups, eine Minute später hatte das andere komplette Team dort Schreibzugriff.

Wolfi Gassler (00:54:58 - 00:55:06)

Und wie hat das funktioniert technisch? Wo war dieser Workflow definiert? Weil der muss ja dann irgendwie auf Organisationsebene oder so definiert sein, oder?

Andy Grunwald (00:55:06 - 00:55:12)

Ja, da gibt es eine kleine Limitierung, muss ich zugeben. Wir haben den Workflow in einem Repository.

Wolfi Gassler (00:55:13 - 00:55:24)

Und da ist dann einfach mit Cron immer gestartet worden und hat dann über die GitHub-API einfach alles abgefragt, die Labels rausgeholt und das dann dementsprechend gesetzt.

Andy Grunwald (00:55:25 - 00:56:15)

Ein anderer klassischer Use-Case, den man oft in Open-Source-Repositories sieht, ist, wenn Issues oder Pull-Requests erstellt werden und da gibt es keine Reaktion, dann nennt man das, okay, da gibt es seit zwei Wochen, drei Wochen, vier Wochen keine Aktivität mehr auf dem Issue oder auf dem Pull-Request, dann nennt sich das, dieses Ticket oder dieser Pull-Request ist stale und viele Repositories und viele Open-Source-Projekte sagen dann, okay, wir schreiben einen automatischen Kommentar in dieses Ticket, hey, seit vier Wochen gibt es hier keine Aktivität, Das Ding hier ist stale. Wenn ich in den nächsten sieben Tagen nichts höre, wird es automatisch zugemacht, weil sonst würden diese Open-Source-Projekte halt einfach nur in Tickets untergehen und wenn man innerhalb von sieben Tagen kein Feedback kriegt, dann sagen sie, okay, dann kann es nicht so wichtig sein, dann schließen die automatisch den Pull-Request oder ähnliches, um einfach halt das Backlog sauber zu halten. Das kann man zum Beispiel auch machen, das ist so ein klassischer Use-Case, den viele machen.

Wolfi Gassler (00:56:15 - 00:56:34)

Kennst du irgendwie eine gute Liste von so Actions, die man in dem Bereich machen könnte oder verwenden könnte, so um Inner Source oder irgendwie auch Open Source irgendwie zu verbessern, die ganzen Workflow oder einen Blog Eintrag oder ähnliches. Gibt's da irgendwas? Kleiner Hint, falls es noch nicht gibt, könntest du einen Blog Eintrag schreiben, Andi.

Andy Grunwald (00:56:34 - 00:56:39)

Es gibt hundertprozentig eine awesome GitHub-Actions-Liste. Würde ich mich mal weit aus dem Wetter lehnen.

Wolfi Gassler (00:56:39 - 00:56:41)

Ja, gibt's für alles eine awesome List.

Andy Grunwald (00:56:41 - 00:56:58)

Deswegen, die verlinkt man natürlich auch in den Show Notes. Und, falls es sie gibt, GitHub selbst hat mal einen tollen Blogpost gemacht. Und zwar haben die einen GitHub-Actions-Hackathon gestartet. um halt wirklich skurrile Anwendungsfälle mit GitHub Actions irgendwie zu highlighten. Den such ich auch noch mal raus. Sehr interessant.

Wolfi Gassler (00:56:58 - 00:56:59)

Verlenken wir natürlich auch.

Andy Grunwald (00:56:59 - 00:57:34)

Wenn ihr noch keine Erfahrung mit GitHub Actions habt, empfehle ich euch wirklich, mal reinzuschauen. Und wenn ihr nicht wisst, was ihr automatisieren wollt, macht auch einfach etwas Kleines, wie zum Beispiel, was ich immer sehr toll fand, es gibt eine GitHub Actions, die nennt sich Welcome Contributors oder ähnliches und immer wenn ein neuer Contributor entweder ein Issue erstellt hat oder ein Pull Request, kommt automatisch ein Bot vorbei und postet auf das Issue. Hey, super, vielen Dank, toll, dass du der erste Contributor hier bist oder toll, dass du das erste Mal vorbeischaust und so weiter. Diese Action heißt halt neue Leute willkommen und das finde ich halt auch sehr schön. Kann man halt alles auch automatisieren.

Wolfi Gassler (00:57:34 - 00:57:37)

Ich mache das immer persönlich mit einer persönlichen Note.

Andy Grunwald (00:57:37 - 00:58:29)

Und du meckerst jetzt hier rum, weil du zu viele E-Mails kriegst. Generell könnt ihr das nutzen, um wirklich alles zu automatisieren. Noch ein paar Limits vielleicht. Wenn ihr einen Cron-Job ausführt und dort keine Aktivität stattfindet, dann kann es sein, dass ihr nach 30 Tagen eine E-Mail kriegt, dass eure GitHub-Actions deaktiviert wird. Also ihr müsst da schon ein bisschen Aktivität auf dem Repository haben, aber sofern eure GitHub Action was zu dem Repository committet, habt ihr natürlich Aktivität. So eine Spirale. Aber das findet ihr schon alles selbst heraus. Ist auf jeden Fall sehr einfach, die Basis GitHub Action einfach mal zu starten. Im Internet gibt es sehr viele Anwendungsfälle, Und vielleicht wollt ihr euch auch mal diese recht komplexe German Tech Podcast Pipeline ansehen. Und vielleicht habt ihr ja in der Woche ein bisschen Zeit, euer Leben mal ein bisschen leichter zu machen.

Wolfi Gassler (00:58:29 - 00:59:05)

Und falls ihr euer Leben schon vereinfacht habt in der Vergangenheit oder eine richtig coole GitHub-Action kennt, bitte lasst uns das wissen. Am besten als Tweet. Wir sind ja auf ING Kiosk auf Twitter erreichbar, aber dann sehen es auch andere. Sonst gerne wie immer stetig at engineeringkiosk.dev und auch unsere WhatsApp-Nummer, die wir für Voice Messages haben, verlinken wir natürlich in den Show Notes. Wir würden uns wirklich freuen auf eine Voice Message, um auch mal die Stimmen von Hörerinnen zu hören. Wäre wirklich cool und würden wir dann gemeinsam natürlich mit euch dementsprechend in eine Episode einbauen mit Rücksprache.

Andy Grunwald (00:59:05 - 00:59:11)

Wolfgang, zum Abschluss. Hast du jetzt das Gefühl, du weißt mehr über GitHub Actions?

Wolfi Gassler (00:59:11 - 00:59:23)

Auf jeden Fall. Vor allem weiß ich jetzt auch mal, dass man auch Events zwischen Repositories senden kann. Da fallen mir schon einige Use Cases ein, die wirklich cool sein können, dass man so richtig Pipelines über verschiedene Repositories hinwegbaut.

Andy Grunwald (00:59:23 - 00:59:28)

Hast du denn jetzt auch Motivation, dir das mal anzusehen? Ein bisschen weiter als ein Copy & Paste.

Wolfi Gassler (00:59:28 - 00:59:36)

Warum? Jetzt habe ich die ganzen perfekten Vorlagen von dir, die kann ich jetzt einfach kopieren, anpassen und habe schon wieder die perfekte Pipeline gebaut. Das ist richtige Faulheit.

Andy Grunwald (00:59:36 - 01:00:05)

Bill Gates wäre stolz auf dich. Das war's von uns zur heutigen Folge. Wir hoffen, ihr konntet ein bisschen was mitnehmen. Ich habe auf jeden Fall tierisch Spaß, jeden Tag mir E-Mails zu schicken. Und ich freu mich auch immer, wie Bolle, wenn irgendeine GitHub-Action wieder irgendwas in mein Repo committed hat, und das ist korrekt. Und ich freu mich einfach, wenn Maschinen meinen Job übernehmen. Weil, ihr wisst ja alle, nur der beste Mitarbeiter macht sich selbst obsolet. Und das mach ich natürlich hier auch.

Wolfi Gassler (01:00:05 - 01:00:27)

Ihr müsst wissen, der Andi schickt dann sogar eine Nachricht, wenn er sich freut. Das heißt, ich bekomme einmal die E-Mail oder die Nachricht über Slack, dass irgendwas getriggert worden ist und dann bekomme ich noch eine manuell geschriebene Antwort von Andi, dass er sich so freut, dass das grad automatisch getriggert wurde. Also es spart ihm extrem viel Zeit und mir auch, weil ich bekomme jetzt drei Messages für irgendeinen Task, der sonst einfach im Hintergrund passieren würde.

Andy Grunwald (01:00:28 - 01:00:45)

Ich kenne sehr viele Teammitglieder, die den ganzen Tag nur meckern, ja? Und dann bist du nur von negativen Mantra umgeben, ja? Und von mir kriegst du tolle Smiley-Nachrichten, die besten Giphy-Memes und so weiter, weil ich mich einfach tierisch freue, dass die Automation funktioniert.

Wolfi Gassler (01:00:45 - 01:00:52)

Ich habe schon zu viel gelernt von deinem Pod-Feedback geben, wie du es immer nennst. Kein Meckern ist Lob genug.

Andy Grunwald (01:00:52 - 01:00:59)

So zu sagen, aber wenn man stolz auf seine Arbeit ist und der Computer macht ein bisschen Arbeit, freue ich mich wie Wolle super.

Wolfi Gassler (01:00:59 - 01:01:06)

Aber es wird uns auf jeden Fall extrem viel Zeit ersparen in Zukunft. Und das soll ja auch eigentlich der Sinn einer Automation sein.

Andy Grunwald (01:01:06 - 01:01:08)

Vielen Dank fürs Zuhören. Habt noch einen schönen Tag.

Wolfi Gassler (01:01:08 - 01:01:10)

Bis bald. Ciao.