Es schien mir, dass es Spaß machen würde, einen Beitrag mit dem Titel "Life of GitHub Action" zu veröffentlichen. Bei der Einführungsschulung von Google werden Sie durch das "Leben der Anfrage" geführt, und ich hatte eines meiner Lieblingselemente. Daher verwende ich einen ähnlichen Ansatz für GitHub Action.
Für diejenigen im Tank ist Actions eine GitHub-Funktion, die letztes Jahr im Universe eingeführt wurde. Willst du Beta-Tester? Geh hierher .
Die allgemeine Idee ist ein GitHub mit Skriptunterstützung, aber ich werde nicht unter Müll leiden und in Erklärungen überlaufen. Führen Sie Sie besser durch die Ereignisse, die beim Start der Aktion auftreten.
Das Problem
Hier ist ein typischer Workflow :
- Ich erstelle eine Pull-Anfrage an das Repository.
- Die Pull-Anfrage wird absorbiert.
- Der Zweig bleibt bis zum Ende der Zeit erhalten und frisst mir den Teil des Gehirns, der Sauberkeit und Ordnung liebt.
Die restlichen Äste sind mein Schmerz, konzentriere dich darauf. Obwohl das Problem allgemein ist, erstellen wir eine Aktion zum Entfernen von Zweigen, nachdem die Pull-Anforderung absorbiert wurde.
Mnogabukaf? Der gesamte Code für die Aktion ist hier .
Workflow-Datei
Wenn Sie möchten - erstellen Sie Aktionen über die Benutzeroberfläche, aber wenn Sie möchten - schreiben Sie eine Workflow-Datei mit Stiften. In diesem Artikel verwende ich nur eine Datei.
So sieht es aus, und ich werde in den Kommentaren zur Datei erklären, was dies alles bedeutet. Es befindet sich in .github/main.workflow in Ihrem Repository.
workflow "on pull request merge, delete the branch" { ## On pull_request defines that whenever a pull request event is fired this ## workflow will be run. on = "pull_request" ## What is the ending action (or set of actions) that we are running. ## Since we can set what actions "need" in our definition of an action, ## we only care about the last actions run here. resolves = ["branch cleanup"] } ## This is our action, you can have more than one but we just have this one for ## our example. ## I named it branch cleanup, and since it is our last action run it matches ## the name in the resolves section above. action "branch cleanup" { ## Uses defines what we are running, you can point to a repository like below ## OR you can define a docker image. uses = "jessfraz/branch-cleanup-action@master" ## We need a github token so that when we call the github api from our ## scripts in the above repository we can authenticate and have permission ## to delete a branch. secrets = ["GITHUB_TOKEN"] }
Ereignis
Da der Artikel "The Life of Action" heißt, beginnen wir mit dem, was für Obskurantismus geschieht. Alle Aktionen werden über das GitHub-Ereignis ausgelöst. Die Liste der unterstützten Ereignisse finden Sie hier .
Oben haben wir das Ereignis pull_request ausgewählt. Es beginnt, wenn eine Pull-Anforderung zugewiesen, nicht zugewiesen, markiert, deaktiviert, geöffnet, bearbeitet, geschlossen, erneut geöffnet, synchronisiert, angefordert wird, um eine Pull-Anforderung anzufordern oder eine Pull-Anforderung zu löschen.
Okay, wir haben diese Veranstaltung gestartet und ...
Mit der Pull-Anfrage stimmt etwas nicht ...
Und hier ist GitHub: „Verdammter Pfannkuchen, mit der Pull-Anfrage stimmt etwas nicht! Ich habe alle Werkzeuge für Probleme gefunden! "
Mit Blick auf die Workflow-Datei (siehe oben) sagt GitHub: "Ich werde jetzt den Workflow starten, um die Pull-Anforderung zu absorbieren, und den Zweig löschen."
Was führt das? Oh, "den Zweig putzen." Lassen Sie mich die Schritte optimieren, die zum Bereinigen des Zweigs erforderlich sind (in diesem Fall gibt es keine), und sie in der Reihenfolge / parallel ausführen, um zum „Bereinigen des Zweigs“ zu gelangen.
Aktion
Hier erklärt GitHub: „Ihr Leute, ich muss hier mit der„ Zweigbereinigung “beginnen. Lass es mich herausfinden. “
Dies bringt uns zurück zum uses unserer Datei. jessfraz/branch-cleanup-action@master auf das Repository: jessfraz/branch-cleanup-action@master .
Dieses Repository enthält die Docker-Datei. Es definiert die Umgebung, in der unsere Aktion ausgeführt wird.
Dockerfile
Schauen Sie es sich an und ich werde versuchen, alles in den Kommentaren zu erklären.
## FROM defines what Docker image we are starting at. A docker image is a bunch ## of files combined in a tarball. ## This image is all the files we need for an Alpine OS environment. FROM alpine:latest ## This label defines our action name, we could have named it butts but ## I decided to be an adult. LABEL "com.github.actions.name"="Branch Cleanup" ## This label defines the description for our action. LABEL "com.github.actions.description"="Delete the branch after a pull request has been merged" ## We can pick from a variety of icons for our action. ## The list of icons is here: https://developer.github.com/actions/creating-github-actions/creating-a-docker-container/#supported-feather-icons LABEL "com.github.actions.icon"="activity" ## This is the color for the action icon that shows up in the UI when it's run. LABEL "com.github.actions.color"="red" ## These are the packages we are installing. Since I just wrote a shitty bash ## script for our Action we don't really need all that much. We need bash, ## CA certificates and curl so we can send a request to the GitHub API ## and jq so I can easily muck with JSON from bash. RUN apk add --no-cache \ bash \ ca-certificates \ curl \ jq ## Now I am going to copy my shitty bash script into the image. COPY cleanup-pr-branch /usr/bin/cleanup-pr-branch ## The cmd for the container defines what arguments should be executed when ## it is run. ## We are just going to call back to my shitty script. CMD ["cleanup-pr-branch"]
Das Skript
Unten finden Sie den Inhalt des Testskripts, das ich ausführe.
#!/bin/bash set -e set -o pipefail # This is populated by our secret from the Workflow file. if [[ -z "$GITHUB_TOKEN" ]]; then echo "Set the GITHUB_TOKEN env variable." exit 1 fi # This one is populated by GitHub for free :) if [[ -z "$GITHUB_REPOSITORY" ]]; then echo "Set the GITHUB_REPOSITORY env variable." exit 1 fi URI=https://api.github.com API_VERSION=v3 API_HEADER="Accept: application/vnd.github.${API_VERSION}+json" AUTH_HEADER="Authorization: token ${GITHUB_TOKEN}" main(){ # In every runtime environment for an Action you have the GITHUB_EVENT_PATH # populated. This file holds the JSON data for the event that was triggered. # From that we can get the status of the pull request and if it was merged. # In this case we only care if it was closed and it was merged. action=$(jq --raw-output .action "$GITHUB_EVENT_PATH") merged=$(jq --raw-output .pull_request.merged "$GITHUB_EVENT_PATH") echo "DEBUG -> action: $action merged: $merged" if [[ "$action" == "closed" ]] && [[ "$merged" == "true" ]]; then # We only care about the closed event and if it was merged. # If so, delete the branch. ref=$(jq --raw-output .pull_request.head.ref "$GITHUB_EVENT_PATH") owner=$(jq --raw-output .pull_request.head.repo.owner.login "$GITHUB_EVENT_PATH") repo=$(jq --raw-output .pull_request.head.repo.name "$GITHUB_EVENT_PATH") default_branch=$( curl -XGET -sSL \ -H "${AUTH_HEADER}" \ -H "${API_HEADER}" \ "${URI}/repos/${owner}/${repo}" | jq .default_branch ) if [[ "$ref" == "$default_branch" ]]; then # Never delete the default branch. echo "Will not delete default branch (${default_branch}) for ${owner}/${repo}, exiting." exit 0 fi echo "Deleting branch ref $ref for owner ${owner}/${repo}..." curl -XDELETE -sSL \ -H "${AUTH_HEADER}" \ -H "${API_HEADER}" \ "${URI}/repos/${owner}/${repo}/git/refs/heads/${ref}" echo "Branch delete success!" fi } main "$@"
Daher hat GitHub unser Skript vorerst in unserer Laufzeit ausgeführt.
GitHub meldet den Status der Aktion an die Benutzeroberfläche und Sie können ihn auf der Registerkarte "Aktionen" sehen.
Hoffentlich bringt dies Klarheit darüber, wie Prozesse in GitHub-Aktionen implementiert werden. Ich kann es kaum erwarten zu sehen, was mit dir passiert.