GitHub Action Life

Ursprünglicher Autor: Jessie Frazelle
  • Übersetzung

Es schien mir, dass es Spaß machen würde, einen Beitrag mit dem Titel "Das Leben der Aktion von GitHub Action" zu kappen. Bei Einführungsschulungen bei Google werden Sie durch das Life of Request-Projekt durchgeführt, und ich hatte eines meiner Lieblingselemente. Daher verwende ich einen ähnlichen Ansatz für GitHub Action.


Actions ist eine GitHub-Funktion, die letztes Jahr bei Universe eingeführt wurde. Möchten Sie Beta-Tester? Geh hier hin .


Die allgemeine Idee ist GitHub mit Skriptunterstützung, aber ich lasse mich nicht mit Müll und Verbreitung in den Erklärungen nieder. Es ist besser, Sie durch die Ereignisse zu führen, die beim Starten der Aktion auftreten.


Das Problem


Hier ist ein typischer Workflow :


  • Ich erstelle eine Pull-Anfrage an das Repository.
  • Pull-Anfrage aufgenommen.
  • Der Zweig bleibt bis zum Ende der Zeit und frisst mir den Teil des Gehirns, der Sauberkeit und Ordnung liebt.


Die verbleibenden Äste sind mein Schmerz, konzentrieren Sie sich darauf. Obwohl das Problem häufig auftritt, erstellen wir eine Aktion, um die Verzweigungen zu entfernen, nachdem der Pull-Pull-Befehl ausgeführt wurde.


Mnogabukaf? Der gesamte Code für die Aktion ist hier .


Workflow-Datei


Wollen - Erstellen Sie Aktionen über die Benutzeroberfläche, und schreiben Sie die Workflow-Datei mit Ziehpunkten, wenn Sie möchten. In diesem Artikel verwende ich nur die Datei.


So sieht es aus, und ich werde erklären, was das alles in den Kommentaren zur Datei bedeutet. Es befindet sich .github/main.workflowin 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 „Das Leben der Aktion“ heißt, beginnen wir mit dem, was für Obskurantismus vor sich geht. Alle Aktionen werden über ein GitHub-Ereignis ausgelöst. Die Liste der unterstützten Ereignisse finden Sie hier .


Oben haben wir eine Veranstaltung ausgewählt pull_request. Sie wird ausgelöst, indem Sie eine Pull-Anforderung zuweisen, eine Zuordnung stornieren, markieren, deaktivieren, öffnen, bearbeiten, schließen, erneut öffnen, synchronisieren, eine Pull-Anforderung anfordern oder eine Pull-Anfrage löschen.


Okay, wir haben diese Veranstaltung gestartet und ...


Bei der Pull-Anfrage ist "etwas" falsch ...

Und hier ist GitHub so: „Blinsky Pancake, mit Pull-Request stimmt etwas nicht! Fick mich aus allen Gewehren nach Problemen! "


GitHub betrachtet die Workflow-Datei (siehe oben) und sagt: "Ich werde den Workflow starten, um die Pull-Anforderung zu akzeptieren, und der Zweig wird gelöscht."


Was führt dazu? Oh, "Filialreinigung". Lassen Sie mich die zum Löschen des Zweigs erforderlichen Aktionen rationalisieren (in diesem Fall gibt es keine), und führen Sie sie nacheinander / parallel aus, um zu einem "Verzweigen des Zweigs" zu gelangen.


Aktion


Hier erklärt GitHub: „Ja, Leute, ich muss die Reinigung der Niederlassung hier durchführen. Lass es mich herausfinden. “


Dies bringt uns zurück zu usesunserem Dateibereich. Wir weisen auf das Repository: jessfraz/branch-cleanup-action@master.


In diesem Repository befindet sich die Dockerfile. Sie definiert die Umgebung, in der unsere Aktion ausgeführt wird.


Dockerfile


Schau es dir 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"]

Skript


Das Folgende ist der Inhalt des von mir ausgeführten Testskripts.


#!/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 "$@"

Im Moment hat GitHub unser Skript in unserer Laufzeitumgebung ausgeführt.
GitHub meldet den Status der Aktion an die Benutzeroberfläche. Sie können ihn auf der Registerkarte "Aktionen" sehen.


Ich hoffe, das bringt Klarheit darüber, wie die Prozesse in GitHub-Aktionen implementiert werden. Ich kann es kaum erwarten zu sehen, was mit dir passiert.


Jetzt auch beliebt: