Trigger del flusso di lavoro manuale in Github Actions


9

Sto impostando Github Actions per un repository di progetti.

Il flusso di lavoro è costituito dai seguenti passaggi:

  • Costruire un'immagine docker
  • Invio dell'immagine in un registro contenitore
  • Implementare una distribuzione Kubernetes.

Tuttavia, ho due diverse distribuzioni Kubernetes: una per lo sviluppo e una per la produzione. Quindi, ho anche due flussi di lavoro di Github Action.

Il flusso di lavoro di Github Action per lo sviluppo viene attivato ogni volta che viene inviato un commit:

on:
  push:
    branches:
    - master

Ma non lo voglio per il mio flusso di lavoro di produzione. Avrei bisogno di un trigger manuale, come un pulsante Invia a produzione . Non ho visto nulla di simile nei documenti.


Esiste un modo per attivare manualmente un flusso di lavoro in Github Actions?

Come posso dividere il mio sviluppo e i miei flussi di lavoro di produzione per ottenere ciò che desidero, su Github Actions, Docker o Kubernetes?

Risposte:


9

Esiste un modo per attivare manualmente un flusso di lavoro in Github Actions?

Ho un piccolo trucco per farlo ...

Con l'evento watch, è possibile attivare manualmente un'azione a stella o sbloccare il repository. Il codice per l'evento nel tuo flusso di lavoro è:

on:
  watch
    types: [started]

So che è una strana merda ma funziona! Tuttavia, non è il modo migliore se si tratta di un repository pubblico con potenziali star.


Come posso dividere il mio sviluppo e i miei flussi di lavoro di produzione per ottenere ciò che desidero, su Github Actions, Docker o Kubernetes?

In Github Actions Voglio dire, puoi fare più flussi di lavoro / lavori e filtrare per rami o eventi mirati. È possibile combinare più eventi, ad esempio attivando un flusso di lavoro per push e con un cron a mezzanotte.


7
Haha, questo è grande:> repository_dispatcha parte, si può combinare watchcon if: github.actor == 'hackerman'per filtrare estranei casuali. O meglio ancora - if: github.actor == github.event.repository.owner.loginper ulteriore "sicurezza": D
Samira,

1
Haha grazie! Sì, buona idea, devo provarlo quando ho tempo! : D
Sarah Abderemane,

1
Perfetto, penso che questo sia il metodo migliore mentre non c'è qualcosa di ufficialmente implementato.
Antoine C.,

5

Aggiornamento : per una soluzione "ChatOps" in stile comando slash, vedere azione slash-command-dispatch . Ciò può consentire di attivare flussi di lavoro con comandi slash (ad es. /deploy) Da problemi e generare commenti di richieste.

Ecco un esempio di base per un deploycomando barra. REPO_ACCESS_TOKENè un token di accesso personale conrepo ambito

name: Slash Command Dispatch
on:
  issue_comment:
    types: [created]
jobs:
  slashCommandDispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Slash Command Dispatch
        uses: peter-evans/slash-command-dispatch@v1
        with:
          token: ${{ secrets.REPO_ACCESS_TOKEN }}
          commands: deploy

Il comando può essere elaborato in questo flusso di lavoro.

name: Deploy Command
on:
  repository_dispatch:
    types: [deploy-command]

Ci sono molte più opzioni e diverse configurazioni. Vedi slash-command-dispatch per le istruzioni complete di utilizzo.

Risposta originale : un repository_dispatchflusso di lavoro può essere attivato manualmente da una chiamata all'API GitHub come segue.

on:
  repository_dispatch:
    types: [production-deploy]
  • [username] è un nome utente GitHub
  • [token]è un token di accesso personale conrepo ambito
  • [repository] è il nome del repository in cui risiede il flusso di lavoro.
curl -XPOST -u "[username]:[token]" \
  -H "Accept: application/vnd.github.everest-preview+json" \
  -H "Content-Type: application/json" \
  https://api.github.com/repos/[username]/[repository]/dispatches \
  --data '{"event_type": "production-deploy"}'

1
Per chiunque sia interessato, è possibile utilizzare un singolo flusso di lavoro per più spedizioni. Ciò che viene inviato come event_typeè disponibile per il flusso di lavoro github.event.action, pertanto è possibile abilitare / disabilitare processi / passaggi specifici quando necessario. PS: PAT non è davvero necessario, iniziare l'arricciatura con -u "[username]:[password]"o -u "[username]"funziona anche (nel secondo caso l'arriccia richiede all'utente la password); più facile da usare in alcuni casi (ad esempio quando si scrivono script che accettano il nome utente come input o script destinati ad essere utilizzati da utenti meno esperti di tecnologia).
Samira,

2

Sebbene il post di Sarah fosse la risposta più vicina e più semplice alla domanda originale, è un po 'confuso, quindi alla fine abbiamo creato un devramo per utilizzare i seguenti trigger:

  • Flusso di lavoro di sviluppo: attivato quando viene effettuata una spinta sul devramo:

    on:
      push:
        branches:    
          - dev
    
  • Flusso di lavoro di produzione: attivato quando viene effettuata una richiesta / unione pull da deva master:

    on:
      pull_request:
        branches:    
          - master
    

1

Modificato per maggiori dettagli / spiegazioni.

Una cosa che puoi fare è chiamare repository_dispatch. È possibile visualizzare la documentazione di GitHub per l'utilizzo di un repository_dispatch qui .

Ad esempio, se si dispone di un flusso di lavoro Azioni GitHub simile al seguente:

on:
  repository_dispatch:
    types: [run_tests]
name: Run tests
jobs:
  test:
    name: Run your tests
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "I just ran all your tests!"

È possibile creare un evento di invio del repository seguendo i passaggi illustrati nella documentazione dell'API GitHub v3 .

Innanzitutto, crea un token di accesso personale (PAT) su GitHub per l'autenticazione.

Quindi, puoi eseguire in questo curlmodo:

curl \
  -H "Authorization: token $YOUR_PAT" \
  --request POST \
  --data '{"event_type": "run_tests"}' \
  https://api.github.com/repos/$USER/$REPOSITORY/dispatches

Allo stesso tempo, volevo anche condividere un piccolo progetto a cui stavo lavorando con un amico che risolve questo esatto problema.

https://www.actionspanel.app/

ActionsPanel utilizza questa stessa repository_dispatchAPI ma lo fa con un token dell'app GitHub in modo da non doverti preoccupare di gestire il tuo PAT. Questo rende anche molto più facile innescare le tue azioni tra team con più persone.

In base alle richieste e al feedback degli utenti, abbiamo incorporato funzionalità per specificare a quale ramo inviare il messaggio repository_dispatche abbiamo persino creato un modo per iniettare i parametri quando si desidera eseguire l'azione.

Configura i tuoi pulsanti con un file yaml dichiarativo che lasci nel repository e ActionsPanel leggerà quel file e creerà dinamicamente la tua UI affinché tu possa attivare le tue azioni.


0

Un altro modo per risolverlo con l'attuale offerta Github Action è quello di creare un productionramo dal master quando è necessaria una distribuzione e attivare un'azione di distribuzione sul productionramo. Il productionramo è essenzialmente uno specchio di master.

on:
  push:
    branches:    
      - master

Le build / push degli sviluppatori possono verificarsi ogni volta che è presente un commit al master.

on:
  push:
    branches:    
      - production

Ad un certo punto del programma di rilascio, è possibile aumentare il PR al productionramo. Questo si occuperà della generazione / distribuzione del prodotto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.