Diese Version von GitHub Enterprise wurde eingestellt am 2021-06-09. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Pre-Receive-Hook-Skript erstellen

Verwenden Sie Pre-Receive-Hook-Skripts, um Anforderungen zum Akzeptieren oder Ablehnen eines Push-Vorgangs anhand der Inhalte zu erstellen.

Im github/platform-samples-Repository finden Sie Beispiele von Pre-Receive-Hooks für GitHub Enterprise Server.

Pre-Receive-Hook-Skript schreiben

A pre-receive hook script executes in a pre-receive hook environment on your GitHub Enterprise Server instance. When you create a pre-receive hook script, consider the available input, output, exit status, and environment variables.

Input (stdin)

After a push occurs and before any refs are updated for the remote repository, the git-receive-pack process on your GitHub Enterprise Server instance invokes the pre-receive hook script. Standard input for the script, stdin, is a string containing a line for each ref to update. Each line contains the old object name for the ref, the new object name for the ref, and the full name of the ref.

<old-value> SP <new-value> SP <ref-name> LF

This string represents the following arguments.

ArgumentBeschreibung
<old-value>Old object name stored in the ref.
When you create a new ref, the value is 40 zeroes.
<new-value>New object name to be stored in the ref.
When you delete a ref, the value is 40 zeroes.
<ref-name>The full name of the ref.

For more information about git-receive-pack, see "git-receive-pack" in the Git documentation. For more information about refs, see "Git References" in Pro Git.

Output (stdout)

The standard output for the script, stdout, is passed back to the client. Any echo statements will be visible to the user on the command line or in the user interface.

Exit-Status

The exit status of a pre-receive script determines if the push will be accepted.

Exit-status valueAktion
0Der Push wird akzeptiert.
ungleich 0Der Push wird abgelehnt.

Umgebungsvariablen

In addition to the standard input for your pre-receive hook script, stdin, GitHub Enterprise Server makes the following variables available in the Bash environment for your script's execution. For more information about stdin for your pre-receive hook script, see "Input (stdin)."

Different environment variables are available to your pre-receive hook script depending on what triggers the script to run.

Always available

The following variables are always available in the pre-receive hook environment.

VariableBeschreibungBeispielwert
$GIT_DIR
Path to the remote repository on the instance/data/user/repositories/a/ab/
a1/b2/34/100001234/1234.git
$GIT_PUSH_OPTION_COUNT
The number of push options that were sent by the client with --push-option. For more information, see "git-push" in the Git documentation.1
$GIT_PUSH_OPTION_N
N entspricht hierbei einer ab 0 beginnenden Ganzzahl. Diese Variable enthält den String der vom Client gesendeten Push-Option. The first option that was sent is stored in GIT_PUSH_OPTION_0, the second option that was sent is stored in GIT_PUSH_OPTION_1, and so on. Weitere Informationen zu den Push-Optionen finden Sie unter „git-push“ in der Git-Dokumentation.abcd
$GITHUB_REPO_NAME
Name of the repository being updated in NAME/OWNER formatocto-org/hello-enterprise
$GITHUB_REPO_PUBLIC
Boolean representing whether the repository being updated is public
  • true: Repository's visibility is public
  • false: Repository's visibility is private or internal
$GITHUB_USER_IP
IP address of client that initiated the push192.0.2.1
$GITHUB_USER_LOGIN
Username for account that initiated the pushoctocat
Available for pushes from the web interface or API

The $GITHUB_VIA variable is available in the pre-receive hook environment when the ref update that triggers the hook occurs via either the web interface or the API for GitHub Enterprise Server. The value describes the action that updated the ref.

WertAktionWeitere Informationen
auto-merge deployment api
Automatic merge of the base branch via a deployment created with the API"Repositories" in the REST API documentation
blob edit
Change to a file's contents in the web interfaceDateien in Ihrem Repository bearbeiten
branch merge api
Merge of a branch via the API"Repositories" in the REST API documentation
branches page delete button
Deletion of a branch in the web interfaceErstellen und Löschen von Branches innerhalb Deines Repositorys"
git refs create api
Creation of a ref via the API"Git database" in the REST API documentation
git refs delete api
Deletion of a ref via the API"Git database" in the REST API documentation
git refs update api
Update of a ref via the API"Git database" in the REST API documentation
git repo contents api
Change to a file's contents via the API"Repositories" in the REST API documentation
merge base into head
Update of the topic branch from the base branch when the base branch requires strict status checks (via Update branch in a pull request, for example)Informationen zu geschützten Branches
pull request branch delete button
Deletion of a topic branch from a pull request in the web interfaceLöschen und Wiederherstellen von Branches in einem Pull Request."
pull request branch undo button
Restoration of a topic branch from a pull request in the web interfaceLöschen und Wiederherstellen von Branches in einem Pull Request."
pull request merge api
Merge of a pull request via the API"Pulls" in the REST API documentation
pull request merge button
Merge of a pull request in the web interfaceEinen Pull Request mergen
pull request revert button
Revert of a pull requestPull Request rückgängig machen
releases delete button
Deletion of a release"Managing releases in a repository"
stafftools branch restore
Restoration of a branch from the site admin dashboard"Site admin dashboard"
tag create api
Creation of a tag via the API"Git database" in the REST API documentation
slumlord (#SHA)
Commit via Subversion"Support for Subversion clients"
web branch create
Creation of a branch via the web interfaceErstellen und Löschen von Branches innerhalb Deines Repositorys"
Available for pull request merges

The following variables are available in the pre-receive hook environment when the push that triggers the hook is a push due to the merge of a pull request.

VariableBeschreibungBeispielwert
$GITHUB_PULL_REQUEST_AUTHOR_LOGIN
Username of account that authored the pull requestoctocat
$GITHUB_PULL_REQUEST_HEAD
The name of the pull request's topic branch, in the format USERNAME:BRANCHoctocat:fix-bug
$GITHUB_PULL_REQUEST_BASE
The name of the pull request's base branch, in the format USERNAME:BRANCHoctocat:main
Available for pushes using SSH authentication
VariableBeschreibungBeispielwert
$GITHUB_PUBLIC_KEY_FINGERPRINT
The public key fingerprint for the user who pushed the changesa1:b2:c3:d4:e5:f6:g7:h8:i9:j0:k1:l2:m3:n4:o5:p6

Berechtigungen festlegen und einen Pre-Receive-Hook per Push-Vorgang an GitHub Enterprise Server übertragen

A pre-receive hook script is contained in a repository on your GitHub Enterprise Server instance. Ein Websiteadministrator muss die Repository-Berechtigungen beachten und sicherstellen, dass nur die richtigen Benutzer über Zugriff verfügen.

Es wird empfohlen, Hooks in einem einzelnen Repository zu konsolidieren. Wenn das konsolidierte Hook-Repository öffentlich ist, kann die Datei README.md verwendet werden, um die Richtliniendurchsetzungen zu erläutern. Darüber hinaus können Beiträge über Pull Requests akzeptiert werden. Pre-Receive-Hooks können jedoch nur auf dem Standardbranch hinzugefügt werden. Für einen Test-Workflow sollten Forks des Repositorys mit entsprechender Konfiguration verwendet werden.

  1. Stellen Sie für Mac-Benutzer sicher, dass die Skripts über Ausführungsberechtigungen verfügen:

    $ sudo chmod +x SCRIPT_FILE.sh

    Stellen Sie für Windows-Benutzer sicher, dass die Skripts über Ausführungsberechtigungen verfügen:

    git update-index --chmod=+x SCRIPT_FILE.sh
  2. Commit and push to the designated repository for pre-receive hooks on your GitHub Enterprise Server instance.

    $ git commit -m "YOUR COMMIT MESSAGE"
    $ git push
  3. Erstellen Sie den Pre-Receive-Hook auf der GitHub Enterprise Server-Instanz.

Pre-Receive-Skripts lokal testen

You can test a pre-receive hook script locally before you create or update it on your GitHub Enterprise Server instance. Eine Methode besteht darin, eine lokale Docker-Umgebung zu erstellen, die als ein Remote-Repository fungiert und als den Pre-Receive-Hook ausführen kann.

  1. Stelle sicher, dass Docker lokal installiert ist.

  2. Erstellen Sie eine Datei namens Dockerfile.dev, die Folgendes enthält:

    FROM gliderlabs/alpine:3.3
    RUN \
      apk add --no-cache git openssh bash && \
      ssh-keygen -A && \
      sed -i "s/#AuthorizedKeysFile/AuthorizedKeysFile/g" /etc/ssh/sshd_config && \
      adduser git -D -G root -h /home/git -s /bin/bash && \
      passwd -d git && \
      su git -c "mkdir /home/git/.ssh && \
      ssh-keygen -t ed25519 -f /home/git/.ssh/id_ed25519 -P '' && \
      mv /home/git/.ssh/id_ed25519.pub /home/git/.ssh/authorized_keys && \
      mkdir /home/git/test.git && \
      git --bare init /home/git/test.git"
    
    VOLUME ["/home/git/.ssh", "/home/git/test.git/hooks"]
    WORKDIR /home/git
    
    CMD ["/usr/sbin/sshd", "-D"]
    
  3. Erstellen Sie ein Pre-Receive-Testskript namens always_reject.sh. Dieses Beispielskript lehnt alle Push-Vorgänge ab, was zum Sperren eines Repositorys nützlich ist:

    #!/usr/bin/env bash
    
    echo "error: rejecting all pushes"
    exit 1
    
  4. Stellen Sie sicher, dass das Skript always_reject.sh über Ausführungsberechtigungen verfügt:

    $ chmod +x always_reject.sh
  5. Erstellen Sie im Verzeichnis, in dem die Dockerfile.dev enthalten ist, ein Image:

    $ docker build -f Dockerfile.dev -t pre-receive.dev .
    > Sending build context to Docker daemon 3.584 kB
    > Step 1 : FROM gliderlabs/alpine:3.3
    >  ---> 8944964f99f4
    > Step 2 : RUN apk add --no-cache git openssh bash && ssh-keygen -A && sed -i "s/#AuthorizedKeysFile/AuthorizedKeysFile/g"  /etc/ssh/sshd_config && adduser git -D -G root -h /home/git -s /bin/bash && passwd -d git && su git -c "mkdir /home/git/.ssh && ssh-keygen -t ed25519 -f /home/git/.ssh/id_ed25519 -P ' && mv /home/git/.ssh/id_ed25519.pub /home/git/.ssh/authorized_keys && mkdir /home/git/test.git && git --bare init /home/git/test.git"
    >  ---> Running in e9d79ab3b92c
    > fetch http://alpine.gliderlabs.com/alpine/v3.3/main/x86_64/APKINDEX.tar.gz
    > fetch http://alpine.gliderlabs.com/alpine/v3.3/community/x86_64/APKINDEX.tar.gz
    ....truncated output....
    > OK: 34 MiB in 26 packages
    > ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
    > Password for git changed by root
    > Generating public/private ed25519 key pair.
    > Your identification has been saved in /home/git/.ssh/id_ed25519.
    > Your public key has been saved in /home/git/.ssh/id_ed25519.pub.
    ....truncated output....
    > Initialized empty Git repository in /home/git/test.git/
    > Successfully built dd8610c24f82
  6. Führen Sie einen Datencontainer aus, der einen generierten SSH-Schlüssel enthält:

    $ docker run --name data pre-receive.dev /bin/true
  7. Kopieren Sie den Pre-Receive-Hook always_reject.sh in den Datencontainer:

    $ docker cp always_reject.sh data:/home/git/test.git/hooks/pre-receive
  8. Führen Sie einen Anwendungscontainer aus, der sshd und den Hook ausführt. Beachten Sie die zurückgegebene Container-ID.

    $ docker run -d -p 52311:22 --volumes-from data pre-receive.dev
    > 7f888bc700b8d23405dbcaf039e6c71d486793cad7d8ae4dd184f4a47000bc58
  9. Kopieren Sie den generierten SSH-Schlüssel aus dem Datencontainer auf den lokalen Computer:

    $ docker cp data:/home/git/.ssh/id_ed25519 .
  10. Ändern Sie die Remote-Instanz eines Test-Repositorys, und übertragen Sie das Repository test.git per Push-Vorgang innerhalb des Docker-Containers. This example uses git@github.com:octocat/Hello-World.git but you can use any repository you want. In diesem Beispiel wird davon ausgegangen, dass Ihr lokaler Computer (127.0.0.1) den Port 52311 bindet. Sie können jedoch eine andere IP-Adresse verwenden, wenn Docker auf einem Remote-Computer ausgeführt wird.

    $ git clone git@github.com:octocat/Hello-World.git
    $ cd Hello-World
    $ git remote add test git@127.0.0.1:test.git
    $ GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 52311 -i ../id_ed25519" git push -u test main
    > Warning: Permanently added '[192.168.99.100]:52311' (ECDSA) to the list of known hosts.
    > Counting objects: 7, done.
    > Delta compression using up to 4 threads.
    > Compressing objects: 100% (3/3), done.
    > Writing objects: 100% (7/7), 700 bytes | 0 bytes/s, done.
    > Total 7 (delta 0), reused 7 (delta 0)
    > remote: error: rejecting all pushes
    > To git@192.168.99.100:test.git
    >  ! [remote rejected] main -> main (pre-receive hook declined)
    > error: failed to push some refs to 'git@192.168.99.100:test.git'

    Beachten Sie, dass der Push abgelehnt wurde, nachdem Sie den Pre-Receive-Hook ausgeführt und die Ausgabe des Skripts wiedergegeben haben.

Weiterführende Informationen