github push action

Action GitHub pour GitHub Push

Les actions GitHub pour transmettre les modifications locales à GitHub à l'aide d'un jeton GitHub autorisé.

Cas d'utilisation

• mettre à jour le nouveau code placé dans votre référentiel, par exemple en exécutant un linter dessus,
• suivre les modifications dans les résultats du script en utilisant Git comme archive,
• publier la page à l'aide de GitHub-Pages,
• refléter les modifications dans un référentiel distinct.

Exigences et prérequis

Pour garantir le bon fonctionnement de vos workflows GitHub Actions, il est important de configurer le GITHUB_TOKEN avec les droits d'accès appropriés pour chaque référentiel.

Suivez ces étapes pour configurer les autorisations nécessaires :

1. Accédez à votre référentiel sur GitHub.
2. Cliquez sur Settings situé dans la barre d'outils du référentiel.
3. Dans la barre latérale gauche, cliquez sur Actions .
4. Sous les paramètres Actions , recherchez et cliquez sur General .
5. Faites défiler jusqu'à la section Workflow permissions .
6. Vous verrez le paramètre d'autorisation par défaut pour le GITHUB_TOKEN . Cliquez sur l'option Read and write permissions .
7. Avec ce paramètre, votre flux de travail pourra lire le contenu du référentiel et repousser les modifications, ce qui est requis pour utiliser cette action GitHub.

Assurez-vous d'enregistrer vos modifications avant de quitter la page des paramètres.

Note

L'octroi d' Read and write permissions permet aux flux de travail de modifier votre référentiel, notamment en ajoutant ou en mettant à jour des fichiers et du code. Assurez-vous toujours que vous faites confiance aux flux de travail que vous activez avec ces autorisations.

Les autorisations GITHUB_TOKEN peuvent également être configurées globalement pour toutes les tâches d'un flux de travail ou individuellement pour chaque tâche.

Cet exemple montre comment définir les autorisations nécessaires pour les étendues contents et pull-requests au niveau du travail :

 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

Pour appliquer des autorisations globalement, ce qui affectera toutes les tâches du flux de travail, vous devez définir la clé permissions au niveau racine du fichier de flux de travail, comme ceci :

 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@v4

Ajustez les niveaux d'autorisation et les étendues en fonction des exigences de votre flux de travail. Pour plus de détails sur chaque niveau d'autorisation, consultez la documentation GitHub.

Usage

Exemple de fichier de flux de travail

Un exemple de workflow pour s'authentifier auprès de GitHub Platform et transmettre les modifications à une référence spécifiée, par exemple une branche déjà disponible :

 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 }}

Un exemple de workflow pour utiliser le paramètre branch pour transmettre les modifications à une branche spécifiée, par exemple une branche Pull Request :

 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 }}

Un exemple de workflow pour utiliser le paramètre force-with-lease pour forcer le transfert vers un référentiel :

 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 : true

Un exemple de workflow pour utiliser un jeton d'application GitHub avec le jeton par défaut dans l'action de paiement. Vous pouvez trouver plus d’informations sur le sujet ici :

 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 }}

Un exemple de workflow pour utiliser le push de jeton non par défaut vers un autre référentiel. Sachez que le flag force-with-lease n'est dans un tel cas pas possible :

 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 : true

Un exemple de workflow pour mettre à jour/écraser une balise existante :

 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 : true

Un exemple de workflow pour s'authentifier auprès de GitHub Platform via Deploy Keys ou en général 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 }}

Un exemple de workflow à pousser vers une branche protégée dans votre référentiel. Sachez qu'il est nécessaire d'utiliser un jeton d'accès personnel et de l'utiliser dans l'action actions/checkout . Cela peut être une bonne idée de spécifier l'indicateur force-with-lease en cas d'erreurs de synchronisation et de push. Si vous souhaitez générer un jeton d'accès personnel adéquat, vous pouvez suivre ces instructions :

 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

Entrées

nom	valeur	défaut	description
github_token	chaîne	${{ github.token }}	GITHUB_TOKEN ou un repo scope Jeton d'accès personnel.
chut	booléen	FAUX	Détermine si ssh/Deploy Keys est utilisé.
bifurquer	chaîne	(défaut)	Branche de destination pour pousser les modifications. Peut être transmis en utilisant ${{ github.ref }} .
forcer	booléen	FAUX	Détermine si la poussée forcée est utilisée.
force_with_lease	booléen	FAUX	Détermine si la poussée forcée avec bail est utilisée. Veuillez spécifier la branche correspondante dans la section ref de l'action de paiement, par exemple ref: ${{ github.head_ref }} . Attention, si vous souhaitez mettre à jour la branche et la balise correspondante merci d'utiliser le paramètre force au lieu de l'option force_with_lease .
atomique	booléen	vrai	Détermine si la poussée atomique est utilisée.
push_to_submodules	chaîne	'sur demande'	Détermine si --recurse-submodules= est utilisé. La valeur définit la stratégie utilisée.
push_only_tags	booléen	FAUX	Détermine si l'action doit uniquement pousser les balises, par défaut false
balises	booléen	FAUX	Détermine si --tags est utilisé.
annuaire	chaîne	'.'	Répertoire vers lequel changer avant de pousser.
dépôt	chaîne	''	Nom du référentiel. Le nom du référentiel par défaut ou vide représente dépôt github actuel. Si vous souhaitez transférer vers un autre référentiel, vous devriez créer un jeton d'accès personnel et utilisez-le comme entrée github_token .

Dépannage

Si vous voyez l'erreur suivante dans la sortie de la tâche et que vous souhaitez mettre à jour une balise existante :

 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'

Veuillez utiliser la force à la place du paramètre force_with_lease . La mise à jour de la balise n'est pas possible avec le paramètre --force-with-lease .

Licence

Le Dockerfile ainsi que les scripts et la documentation associés à ce projet sont publiés sous la licence MIT.

Aucune affiliation avec GitHub Inc.

GitHub sont des marques déposées de GitHub, Inc. Le nom GitHub utilisé dans ce projet est uniquement à des fins d'identification. Le projet n'est en aucun cas associé à GitHub Inc. et n'est pas une solution officielle de GitHub Inc. Il a été mis à disposition afin de faciliter l'utilisation du site GitHub.