Ręczne wyzwalacze przepływu pracy w Github Actions

Konfiguruję akcje Github dla repozytorium projektu.

Przepływ pracy składa się z następujących kroków:

• Budowanie obrazu dokera
• Przekazywanie obrazu do rejestru kontenera
• Wdrożyć wdrożenie Kubernetes.

Mam jednak dwa różne wdrożenia Kubernetes: jedno do programowania i jedno do produkcji. Dlatego mam także dwa przepływy pracy w Github Action.

Przepływ pracy Akcji Github dla programowania jest uruchamiany za każdym razem, gdy wypychane jest zatwierdzenie:

on:
  push:
    branches:
    - master

Ale nie chcę tego w moim procesie produkcyjnym. Potrzebowałbym ręcznego wyzwalacza, takiego jak przycisk Wyślij do produkcji . Nie widziałem nic podobnego w dokumentacji.

Czy istnieje sposób, aby ręcznie uruchomić przepływ pracy w Github Actions?

Jak mogę rozdzielić proces projektowania i produkcyjny, aby osiągnąć to, czego chcę, w Github Actions, Docker lub Kubernetes?

Czy istnieje sposób, aby ręcznie uruchomić przepływ pracy w Github Actions?

Muszę to zrobić trochę hack ...

Za pomocą zdarzenia oglądania możesz ręcznie uruchomić akcję gwiazdką lub odznaczyć gwiazdkę repozytorium. Kod zdarzenia w twoim przepływie pracy to:

on:
  watch
    types: [started]

Wiem, że to dziwne gówno, ale działa! Niemniej jednak nie jest to najlepszy sposób, jeśli jest to publiczne repozytorium z potencjalnymi gwiazdami.

Jak mogę rozdzielić proces projektowania i produkcyjny, aby osiągnąć to, czego chcę, w Github Actions, Docker lub Kubernetes?

Chodzi mi o to, że w Github Actions możesz wykonywać wiele przepływów pracy / zadań i filtrować według ukierunkowanych gałęzi lub zdarzeń. Możesz łączyć wiele zdarzeń, na przykład uruchamiać przepływ pracy dla wypychania i z cronem o północy.

Aktualizacja : W przypadku rozwiązania „ChatOps” w stylu polecenia ukośnika zobacz akcję slash-command-dispatch . Dzięki temu możesz uruchamiać przepływy pracy za pomocą poleceń ukośnika (np. /deploy) Z wydania i komentować żądania żądania.

Oto podstawowy przykład deploypolecenia ukośnika. REPO_ACCESS_TOKENjest osobistym tokenem o repozasięgu

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

Polecenie można przetwarzać w tym przepływie pracy.

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

Istnieje wiele innych opcji i różnych konfiguracji. Zobacz instrukcje slash-command-dispatch, aby uzyskać pełne instrukcje użytkowania.

Oryginalna odpowiedź : repository_dispatchprzepływ pracy można ręcznie uruchomić przez wywołanie interfejsu API GitHub w następujący sposób.

on:
  repository_dispatch:
    types: [production-deploy]

• [username] to nazwa użytkownika GitHub
• [token]jest osobistym tokenem o repozasięgu
• [repository] to nazwa repozytorium, w którym znajduje się przepływ pracy.

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

Chociaż post Sarah był najbliższą i najprostszą odpowiedzią na pierwotne pytanie, jest nieco zuchwały, więc w końcu stworzyliśmy devgałąź, która używa następujących wyzwalaczy:

• Przepływ pracy programistycznej: uruchamiany po wypchnięciu devgałęzi:

  on:
    push:
      branches:    
        - dev
  

• Przepływ pracy produkcji: uruchamiany, gdy wysyłane jest żądanie ściągnięcia / scalenia z devdo master:

  on:
    pull_request:
      branches:    
        - master
  

Edytowane w celu uzyskania bardziej szczegółowych informacji / wyjaśnień.

Jedną rzeczą, którą możesz zrobić, to zadzwonić repository_dispatch. Możesz wyświetlić dokumentację GitHub dotyczącą korzystania z repository_dispatch tutaj .

Na przykład jeśli masz przepływ pracy Akcje GitHub, który wygląda następująco:

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!"

Możesz utworzyć zdarzenie wysyłki repozytorium, wykonując kroki opisane w dokumentacji API GitHub v3 .

Najpierw utwórz osobisty token dostępu (PAT) na GitHub do uwierzytelnienia.

Następnie możesz biegać curl tak:

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

Jednocześnie chciałem podzielić się małym projektem, nad którym pracowałem z kumplem, który rozwiązuje dokładnie ten problem.

https://www.actionspanel.app/

ActionsPanel używa tego samego repository_dispatchinterfejsu API, ale robi to za pomocą tokena aplikacji GitHub, dzięki czemu nie musisz się martwić o zarządzanie własnym PAT. To także znacznie ułatwia uruchamianie działań w zespołach z wieloma osobami.

W oparciu o żądania użytkowników i opinie, wbudowaliśmy funkcje określające, do której gałęzi wysłać repository_dispatch, a nawet stworzyliśmy sposób wprowadzania parametrów, gdy chcesz wykonać akcję.

Skonfigurujesz przyciski przy użyciu deklaratywnego pliku yaml, który pozostawiasz w repozytorium, a ActionsPanel odczyta ten plik i dynamicznie utworzy interfejs użytkownika, aby wyzwolić działania.

Innym sposobem rozwiązania tego problemu w obecnej ofercie Github Action jest utworzenie productiongałęzi z poziomu master, gdy potrzebne jest wdrożenie i wyzwalanie akcji wdrażania w productiongałęzi. productionOddział jest zasadniczo lustrzanym master.

on:
  push:
    branches:    
      - master

Kompilacje / wypychanie deweloperów może się zdarzyć, gdy nastąpi zatwierdzenie do master.

on:
  push:
    branches:    
      - production

W pewnym momencie harmonogramu wydań możesz podnieść PR do productionoddziału. To zajmie się kompilacją / wdrożeniem prod.