Jak automatycznie publikować wydania GitHub z tagów Git
Wersje GitHub zapewniają użytkownikom końcowym łatwą metodę pobierania plików binarnych oprogramowania z różnymi wersjami. Możesz tworzyć je ręcznie, ale o wiele łatwiej jest pozwolić GitHub Actions tworzyć je automatycznie przy użyciu tagów wersji utworzonych w Twoim repozytorium.
Używanie oznaczonych wydań
Tagi to istniejąca funkcja w Git, z rozszerzoną obsługą oferowaną przez GitHub z wydaniami, które oferują miejsce do hostowania plików binarnych z powiązanymi dziennikami zmian.
Możesz utworzyć znacznik podobnie jak gałąź, z wyjątkiem tego, że jest to stały punkt, który się nie porusza i zawsze wskazuje na określone zatwierdzenie. Jest to przydatne do tworzenia wydań z wersjami, a większość ludzi będzie tworzyć tagi przy użyciu semantycznego formatu wersjonowania (Major.Minor.Patch).
Tagi można przesyłać do GitHub, gdzie można ich używać w innych przepływach pracy automatyzacji. W takim przypadku skonfigurujemy skrypt GitHub Actions, który będzie nasłuchiwał zatwierdzeń zawierających oznaczone wydania i automatycznie publikował artefakty kompilacji w wydaniu.
Konfigurowanie akcji GitHub
Najpierw upewnij się, że masz działającą kompilację GitHub Actions i że skrypty kompilacji działają poprawnie. Dokładna konfiguracja przepływu pracy będzie zależeć od rodzaju tworzonego projektu, ale generalnie nie chcesz debugować dwóch problemów naraz, więc powinieneś dodać publikowanie wersji, gdy masz już działające artefakty. Możesz przeczytać nasz przewodnik dotyczący konfigurowania kompilacji GitHub Actions, aby dowiedzieć się więcej.
Pierwszą rzeczą do zrobienia jest edycja sekcji „on” skryptu Actions, aby działała również podczas tworzenia tagów. Domyślnie prawdopodobnie masz zdarzenie „push” do śledzenia wydań lub gałęzi master. Musisz dodać tagi i ustawić filtr. W przypadku wszystkich tagów po prostu użyj symbolu wieloznacznego:
Na końcu przepływu pracy, po zbudowaniu wszystkiego, utworzymy wpis Release. Jest to krok dwuczęściowy — najpierw musimy utworzyć nowy obiekt Release ze wszystkimi metadanymi, a następnie możemy użyć w tym celu wygenerowanego adresu URL publikacji, aby przesłać artefakty. Jeśli masz wiele artefaktów, możesz utworzyć wiele kroków przesyłania.
W obu przypadkach będziemy chcieli wykonać te kroki tylko wtedy, gdy przepływ pracy jest uruchomiony z powodu tagu. Możemy to zrobić za pomocą prostego ifsprawdzenia i sprawdzić, czy github.refobiekt jest znacznikiem, który przechowuje nazwę ref gałęzi lub znacznika, który uruchomił przepływ pracy.
Pierwszym krokiem jest utworzenie obiektu Release, co można wykonać w następnym kroku. Tokenu GitHub nie trzeba tworzyć ręcznie — to specjalny token, do którego zawsze można się odwoływać ze skryptów Actions.
- name: Create Release
if: startsWith(github.ref, 'refs/tags/')
uses: actions/create-release@v1
id: create_release
with:
draft: false
prerelease: false
release_name: ${{ github.ref }}
tag_name: ${{ github.ref }}
body_path: CHANGELOG.md
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Zauważ tutaj, że dziennik zmian dla wydania jest przechowywany w CHANGELOG.md, który musi istnieć, aby przepływ pracy działał poprawnie . Możesz edytować to z każdym tagiem, aby zmienić przecenę wyświetlaną przez GitHub na stronie wydania. Istnieją narzędzia do automatycznego generowania tego za pomocą komunikatów zatwierdzających, ale większość zespołów i tak ma własną metodę zarządzania tym.
Następnie możesz rozpocząć przesyłanie artefaktów. Wykorzystuje to adres URL przesyłania z poprzedniego kroku i musisz zdefiniować ścieżkę, w której można go znaleźć, wraz z wyświetlaną nazwą zasobu.
- name: Upload Release
if: startsWith(github.ref, 'refs/tags/')
uses: actions/upload-release-asset@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ steps.create_release.outputs.upload_url }}
asset_path: Oxide.Ext.Sanctuary/bin/Release/net48/Oxide.Ext.Sanctuary.dll
asset_name: Oxide.Ext.Sanctuary.dll
asset_content_type: application/octet-stream
Należy zauważyć, że typ zawartości jest ustawiony na octet-stream, co jest typowe dla danych binarnych, takich jak pliki wykonywalne i biblioteki DLL. Jeśli publikujesz plik ZIP lub inny rodzaj pliku, będziesz chciał to zmienić, ale dotyczy to tylko elementów wizualnych na stronie wydania.
Teraz możesz zatwierdzić zmiany w przepływie pracy Actions, a następnie utworzyć nowy tag i przekazać go do GitHub. Powinieneś zobaczyć tworzenie nowego przebiegu przepływu pracy, z wyjątkiem tego, że zamiast uciekać z gałęzi głównej, jest on uruchomiony z powodu tagu:
Po zakończeniu zobaczysz wydanie na pasku bocznym GitHub.
Dodaj komentarz