github push action
v0.8.0
Die GitHub-Aktionen zum Übertragen lokaler Änderungen an GitHub mithilfe eines autorisierten GitHub-Tokens.
Um sicherzustellen, dass Ihre GitHub Actions-Workflows ordnungsgemäß funktionieren, ist es wichtig, den GITHUB_TOKEN mit den entsprechenden Zugriffsrechten für jedes Repository zu konfigurieren.
Befolgen Sie diese Schritte, um die erforderlichen Berechtigungen einzurichten:
Settings .Actions .Actions General und klicken Sie darauf.Workflow permissions .GITHUB_TOKEN . Klicken Sie auf die Option Read and write permissions .Stellen Sie sicher, dass Sie Ihre Änderungen speichern, bevor Sie die Einstellungsseite verlassen.
Notiz
Durch die Gewährung von Read and write permissions können Workflows Ihr Repository ändern, einschließlich des Hinzufügens oder Aktualisierens von Dateien und Code. Stellen Sie immer sicher, dass Sie den Workflows vertrauen, die Sie mit diesen Berechtigungen aktivieren.
Die GITHUB_TOKEN Berechtigungen können auch global für alle Jobs in einem Workflow oder individuell für jeden Job konfiguriert werden.
Dieses Beispiel zeigt, wie die erforderlichen Berechtigungen für die contents und pull-requests -Bereiche auf Jobebene festgelegt werden:
jobs :
job1 :
runs-on : ubuntu-latest
permissions : # Job-level permissions configuration starts here
contents : write # 'write' access to repository contents
pull-requests : write # 'write' access to pull requests
steps :
- uses : actions/checkout@v4 Um Berechtigungen global anzuwenden, was sich auf alle Jobs innerhalb des Workflows auswirkt, würden Sie den permissions auf der Stammebene der Workflowdatei definieren, etwa so:
permissions : # Global permissions configuration starts here
contents : read # 'read' access to repository contents
pull-requests : write # 'write' access to pull requests
jobs :
job1 :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4Passen Sie die Berechtigungsstufen und -bereiche entsprechend den Anforderungen Ihres Workflows an. Weitere Einzelheiten zu den einzelnen Berechtigungsstufen finden Sie in der GitHub-Dokumentation.
Ein Beispielworkflow zur Authentifizierung bei der GitHub-Plattform und zum Pushen der Änderungen an eine bestimmte Referenz, z. B. einen bereits verfügbaren Zweig:
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
persist-credentials : false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token.
fetch-depth : 0 # otherwise, there would be errors pushing refs to the destination repository.
- name : Create local changes
run : |
...
- name : Commit files
run : |
git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
github_token : ${{ secrets.GITHUB_TOKEN }}
branch : ${{ github.ref }}Ein Beispielworkflow zur Verwendung des Branch-Parameters, um die Änderungen an einen bestimmten Branch, z. B. einen Pull-Request-Branch, zu übertragen:
name : Example
on : [pull_request, pull_request_target]
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
ref : ${{ github.head_ref }}
fetch-depth : 0
- name : Commit files
run : |
git config --local user.email "github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
branch : ${{ github.head_ref }}Ein Beispielworkflow zur Verwendung des Force-with-Lease-Parameters, um den Push in ein Repository zu erzwingen:
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
ref : ${{ github.head_ref }}
fetch-depth : 0
- name : Commit files
run : |
git config --local user.email "github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
force_with_lease : trueEin Beispiel-Workflow zur Verwendung eines GitHub-App-Tokens zusammen mit dem Standard-Token innerhalb der Checkout-Aktion. Weitere Informationen zum Thema finden Sie hier:
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
ref : ${{ github.head_ref }}
fetch-depth : 0
persist-credentials : false
- name : Generate Githup App Token
id : generate_token
uses : tibdex/github-app-token@v1
with :
app_id : ${{ secrets.APP_ID }}
installation_id : ${{ secrets.INSTALLATION_ID }}
private_key : ${{ secrets.APP_PRIVATE_KEY }}
- name : Commit files
run : |
git config --local user.email "[email protected]"
git config --local user.name "Test"
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
github_token : ${{ env.TOKEN }}Ein Beispielworkflow zur Verwendung des nicht standardmäßigen Token-Push in ein anderes Repository. Beachten Sie, dass das Force-with-Lease-Flag in einem solchen Fall nicht möglich ist:
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
ref : ${{ github.head_ref }}
fetch-depth : 0
token : ${{ secrets.PAT_TOKEN }}
- name : Commit files
run : |
git config --local user.email "[email protected]"
git config --local user.name "Test"
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
github_token : ${{ secrets.PAT_TOKEN }}
repository : Test/test
force : trueEin Beispielworkflow zum Aktualisieren/Überschreiben eines vorhandenen Tags:
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
ref : ${{ github.head_ref }}
fetch-depth : 0
- name : Commit files
run : |
git config --local user.email "github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"
git tag -d $GITHUB_REF_NAME
git tag $GITHUB_REF_NAME
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
force : true
tags : trueEin Beispielworkflow zur Authentifizierung bei der GitHub-Plattform über Deploy Keys oder allgemein SSH:
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
ssh-key : ${{ secrets.SSH_PRIVATE_KEY }}
persist-credentials : true
- name : Create local changes
run : |
...
- name : Commit files
run : |
git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
ssh : true
branch : ${{ github.ref }} Ein Beispielworkflow zum Pushen in einen geschützten Zweig in Ihrem Repository. Beachten Sie, dass die Verwendung eines persönlichen Zugriffstokens und dessen Verwendung innerhalb der actions/checkout Aktion erforderlich ist. Im Falle von Synchronisierungs- und Push-Fehlern kann es sinnvoll sein, das Force-with-Lease-Flag anzugeben. Wenn Sie ein geeignetes persönliches Zugriffstoken generieren möchten, können Sie diesen Anweisungen folgen:
jobs :
build :
runs-on : ubuntu-latest
steps :
- uses : actions/checkout@v4
with :
ref : ${{ github.head_ref }}
fetch-depth : 0
token : ${{ secrets.PAT_TOKEN }}
- name : Commit files
run : |
git config --local user.email "[email protected]"
git config --local user.name "Test"
git commit -a -m "Add changes"
- name : Push changes
uses : ad-m/github-push-action@master
with :
github_token : ${{ secrets.PAT_TOKEN }}
repository : Test/test
force_with_lease : true| Name | Wert | Standard | Beschreibung |
|---|---|---|---|
| github_token | Zeichenfolge | ${{ github.token }} | GITHUB_TOKEN oder ein Repo-Bereich Persönliches Zugriffstoken. |
| ssh | Boolescher Wert | FALSCH | Legt fest, ob ssh/Deploy Keys verwendet wird. |
| Zweig | Zeichenfolge | (Standard) | Zielzweig zum Übertragen von Änderungen. Kann mit ${{ github.ref }} übergeben werden. |
| Gewalt | Boolescher Wert | FALSCH | Legt fest, ob Force Push verwendet wird. |
| force_with_lease | Boolescher Wert | FALSCH | Legt fest, ob Force-with-Lease-Push verwendet wird. Bitte geben Sie den entsprechenden Zweig im ref Abschnitt der Checkout-Aktion an, z. B. ref: ${{ github.head_ref }} . Beachten Sie: Wenn Sie den Zweig und das entsprechende Tag aktualisieren möchten, verwenden Sie bitte den force Parameter anstelle der Option force_with_lease . |
| atomar | Boolescher Wert | WAHR | Bestimmt, ob Atomic Push verwendet wird. |
| push_to_submodules | Zeichenfolge | 'auf Anfrage' | Bestimmt, ob --recurse-submodules= verwendet wird. Der Wert definiert die verwendete Strategie. |
| push_only_tags | Boolescher Wert | FALSCH | Legt fest, ob die Aktion nur die Tags pushen soll. Der Standardwert ist „false“. |
| Tags | Boolescher Wert | FALSCH | Bestimmt, ob --tags verwendet wird. |
| Verzeichnis | Zeichenfolge | '.' | Verzeichnis, in das vor dem Pushen gewechselt werden soll. |
| Repository | Zeichenfolge | '' | Repository-Name. Der Standard- oder leere Repository-Name stellt dar aktuelles Github-Repository. Wenn Sie in ein anderes Repository pushen möchten, Sie sollten ein persönliches Zugriffstoken erstellen und verwenden Sie es als github_token Eingabe. |
Wenn in der Ausgabe des Jobs die folgende Fehlermeldung angezeigt wird und Sie ein vorhandenes Tag aktualisieren möchten:
To https://github.com/Test/test_repository
! [rejected] 0.0.9 -> 0.0.9 (stale info)
error: failed to push some refs to 'https://github.com/Test/test_repository'
Bitte verwenden Sie den Parameter force anstelle des Parameters force_with_lease . Die Aktualisierung des Tags ist mit dem Parameter --force-with-lease nicht möglich.
Die Docker-Datei sowie die zugehörigen Skripte und Dokumentationen in diesem Projekt werden unter der MIT-Lizenz veröffentlicht.
GitHub sind eingetragene Marken von GitHub, Inc. Der in diesem Projekt verwendete GitHub-Name dient nur zu Identifikationszwecken. Das Projekt steht in keiner Verbindung zu GitHub Inc. und ist keine offizielle Lösung von GitHub Inc. Es wurde zur Verfügung gestellt, um die Nutzung der Website GitHub zu erleichtern.
