vite github pages deployer
v1.4.0
Stellen Sie Ihre Vite-Anwendung auf einen Blick auf Github-Seiten bereit.
vite als build -Tool verwenden. Vue, React, Svelte ... Was auch immer! - name: Vite Github Pages Deployer
uses: skywarth/[email protected]
Sie können diese Aktion einfach verwenden, indem Sie sie entsprechend zu yaml Dateien Ihrer Aktion hinzufügen.
Stellen Sie sicher, dass Sie diesen Schritt nach Ihrem „Zur Kasse gehen“-Schritt platzieren.
- name : Vite Github Pages Deployer
uses : skywarth/[email protected]
id : deploy_to_pages Sie müssen den Umgebungsabschnitt direkt vor den steps platzieren. Dies ermöglicht die Freigabe der Umgebung auf der Registerkarte „Umgebungen“.
environment :
name : demo
url : ${{ steps.deploy_to_pages.outputs.github_pages_url }}Sie müssen die richtige Berechtigung für die Aktion festlegen, um Umgebung und Artefakt erfolgreich freizugeben. Wenn Sie dies nicht tun, erhalten Sie möglicherweise Berechtigungsfehler.
Die Berechtigungserklärung kann an einer beliebigen Stelle vor dem Abschnitt jobs: “ platziert werden.
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions :
contents : read
pages : write
id-token : writeWenn Sie nicht wissen, was Sie tun sollen, welche Aktionen es gibt oder wo Sie die Codeteile im Verwendungsabschnitt platzieren sollen, führen Sie die folgenden Schritte aus:
./.github/workflows/vite-github-pages-deploy.yml . Erstellen Sie also im Wesentlichen einen .github Ordner im Stammverzeichnis Ihres Projekts und erstellen Sie dort eine yml Datei.master Zweig oder Ihrer nächsten manuellen Ausführung über die Registerkarte „Aktionen“ wird diese Aktion ausgeführt und Ihr Projekt wird auf Github-Seiten bereitgestellt. name : Vite Github Pages Deploy
on :
# Runs on pushes targeting the default branch
push :
branches : ["master", "main"]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch :
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions :
contents : read
pages : write
id-token : write
concurrency :
group : " pages "
cancel-in-progress : false
jobs :
# Build job
build :
runs-on : ubuntu-latest
environment :
name : demo
url : ${{ steps.deploy_to_pages.outputs.github_pages_url }}
steps :
- name : Checkout
uses : actions/checkout@v3
- name : Vite Github Pages Deployer
uses : skywarth/vite-github-pages-deployer@master
id : deploy_to_pages
Möchten Sie es in Aktion sehen? Klar, besuchen Sie dieses Vue-Projekt, um es live zu sehen: https://github.com/skywarth/country-routing-algorithm-demo-vue
public_base_path (optional)| Typ | Standard | Beispielwerte |
|---|---|---|
string | /{your-repo-name} ODER / wenn Sie CNAME haben | /my-vite-project |
Öffentliche Basispfadzeichenfolge für Vite. Dies wirkt sich auf Routing, Verlauf und Asset-Links aus. Stellen Sie sicher, dass Sie die entsprechenden Informationen bereitstellen, da GitHub Pages Ihre App in einem Verzeichnis unter einer Subdomain speichert. Wenn Sie eine Bereitstellung auf einer alternativen Plattform wie Vercel planen, sollten Sie einfach / angeben.
Unter normalen Umständen müssen Sie diesen Parameter nicht angeben/überschreiben, die Aktion setzt ihn entsprechend auf Ihren Repo-Namen.
public_base_path aufgelöst:public_base_path bereitgestellt wird, wird er trotzdem verwendet.public_base_path NICHT bereitgestellt wird:CNAME Datei für die Einrichtung einer benutzerdefinierten GitHub Pages-Domäne verfügt, wird der Standardwert public_base_path in / aufgelöst.CNAME hat, wird der Standardwert public_base_path in /{your-repo-name} aufgelöst. Den Vorschlag zur CNAME-Erweiterung finden Sie hier
Ich danke Greg Sadetsky für seinen Vorschlag zum Wechsel des Standardwerts dieser Eingabe. Vielen Dank auch für seine Mitarbeit bei der Erläuterung der benutzerdefinierten Domäneneinstellungen der GitHub-Seiten und der Testphase dieser Änderungen.
build_path (optional)| Typ | Standard | Beispielwerte |
|---|---|---|
string | ./dist | - ./deploy- ./dist/browser |
Welchen Ordner soll Ihre GitHub-Seite nach dem Erstellungsprozess als Stammverzeichnis verwenden? Es ist einfach Ihr Build-Ausgabeverzeichnis, z. B. ./dist . Wenn Ihre vite -Konfiguration in einen anderen Ordner als ./dist exportiert wird, sollten Sie ihn als Parameter übergeben.
install_phase_node_env (optional)| Typ | Standard | Beispielwerte |
|---|---|---|
string | dev | - dev- production- staging- test- my-little-pony-env |
Knotenumgebung, die für die Installation von Abhängigkeiten verwendet wird. Es ist unbedingt erforderlich, dass Sie eine Umgebung verwenden, die „vite“ als Abhängigkeit hat . Im Allgemeinen und natürlich ist dieses env dev .
Wenn Sie kein NODE_ENV bereitstellen, das vite als Abhängigkeit hat (überprüfen Sie Ihre package.json), erhalten Sie sh: 1: vite: not found .
build_phase_node_env (optional)| Typ | Standard | Beispielwerte |
|---|---|---|
string | production | - dev- production- staging- test- my-little-pony-env |
Knotenumgebung, die für die Build-Phase verwendet wird. Sie können hierfür einen beliebigen gültigen NODE_ENV-Wert angeben, da Knotenerstellungen dazu neigen, sich für verschiedene Umgebungen zu ändern (z. B.: Sie verbergen Debugging-Funktionen vor der Produktion).
artifact_name (optional)| Typ | Standard | Beispielwerte |
|---|---|---|
string | github-pages | - what-a-cool-artifact- ah-yes-ze-artifact |
Gewünschter Name für das freigelegte Artefakt. Dieser Name ist im Job sichtbar und wird als Artefaktname verwendet.
package_manager (optional)| Typ | Standard | Beispielwerte |
|---|---|---|
string | npm | - npm- yarn |
Geben Sie den bevorzugten Paketmanager an. Es wird zum Installieren von Abhängigkeiten und zum Erstellen des dist verwendet. Wenn Sie beispielsweise yarn als Paketmanager für das Projekt bevorzugen/verwenden, können Sie package_manager: 'yarn' als Eingabe übergeben, die dann als yarn install und yarn build verwendet wird.
debug_mode (optional)| Typ | Standard | Beispielwerte |
|---|---|---|
string | 'false' | - 'true'- 'false' |
Steuert den Debug-Modus, Zeichenfolge, 'true' steht für „on“. Wenn es aktiviert ist, werden bestimmte Informationen zu bestimmten Schritten ausgegeben. Wird hauptsächlich für die Entwicklung verwendet, aber Sie können es nach Belieben verwenden, um Ihre Umgebung und Variablen zu überprüfen.
github_pages_url| Typ | Beispielwerte |
|---|---|
string | - 'https://skywarth.github.io/country-routing-algorithm-demo-vue/' |
Dieser Ausgabewert soll verwendet werden, um die Github-Seiten-URL nach der Bereitstellung abzurufen. Der Zugriff kann folgendermaßen erfolgen: ${{ steps.deploy_to_pages.outputs.github_pages_url }} (deploy_to_pages ist die ID des Schritts, den Sie mit dem Vite Github Pages Deployer ausführen).
Es wird erwartet, dass es als Möglichkeit zum Veröffentlichen der Umgebung während des Jobs verwendet wird, etwa so:
environment:
name: demo
url: ${{ steps.deploy_to_pages.outputs.github_pages_url }}
Sehen Sie sich den Beispiel-Workflow an, um zu verstehen, wie Sie diese Ausgabe nutzen können
Fehler: Environment URL '' is not a valid http(s) URL, so it will not be shown as a link in the workflow graph.
Ursache: Die Umgebungsdeklaration fehlt in der Aktion. Sie sollten sie zu Ihrer Aktions- yaml Datei hinzufügen, um sowohl den Fehler/die Warnung zu beheben als auch die freigegebene Umgebung auf der Registerkarte environments im Repository anzuzeigen.
Lösung: Fügen Sie Ihrer Aktion Folgendes hinzu:
environment :
# Name could be whatever you wish. It'll be visible publicly under the environments tab.
name : demo
url : ${{ steps.deploy_to_pages.outputs.github_pages_url }}deploy_to_pages mit der id des Schritts identisch sein sollte, in dem Sie den Vite GitHub pages deployer ausführen. Einzelheiten finden Sie im Beispielworkflow.
GITHUB_TOKEN Fehler: Error: Ensure GITHUB_TOKEN has permission "id-token: write".
Ursache: Die Berechtigung wurde nicht wie im Abschnitt „Nutzung“ angegeben festgelegt. Wenn der Aktion nicht die entsprechenden Berechtigungen erteilt werden, können keine Artefakte oder Umgebungen erstellt werden.
Lösung: Fügen Sie den folgenden Code zu Berechtigungen zu Ihrer Aktions- yaml Datei hinzu.
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
Sehen Sie sich den Beispielworkflow an, wenn Sie nicht sicher sind, wo Sie ihn platzieren sollen.
package-lock.json ist nicht vorhanden, wenn npm als Paketmanager-Präferenz verwendet wird. Fehler: The command can only install with an existing package-lock.json...
Ursache: Wenn die Eingabeeinstellung package_manager auf npm (oder standardmäßig nicht zugewiesen) eingestellt ist, werden Abhängigkeiten mithilfe von npm ci installiert, das package-lock.json verwendet. Stellen Sie in diesem Fall sicher, dass package-lock.json in Ihrem Projektstammverzeichnis vorhanden ist.
Lösung: Fügen Sie Ihre package-lock.json Datei zu Ihrem Projekt hinzu. Wenn es sich im Verzeichnis befindet, aber nicht im Repository erscheint, überprüfen Sie Ihre Gitignore-Datei und entfernen Sie sie aus Gitignore. Alternativ können Sie yarn über die Parametereingabe package_manager der Aktion als Ihren bevorzugten Paketmanager für die Abhängigkeitsinstallation festlegen.
bash-files ) bash-files )Gibt es etwas, das Sie benötigen, entspricht diese Aktion nicht Ihren Erwartungen oder fehlen bestimmte Zukunftsaussichten, die Sie daran hindern, sie zu nutzen? Öffnen Sie ein Problem und wir fügen es der Roadmap/TODOs hinzu. Beiträge sind willkommen.
${{github.action_path}} : Gibt Ihnen das Verzeichnis für diese Aktion selbst.
${{ github.workspace }} : Gibt Ihnen das Verzeichnis des Projekts (z. B.: /home/runner/work/country-routing-algorithm-demo-vue/country-routing-algorithm-demo-vue)
Wenn Sie eine SH-Datei in die Bash-Shell importieren, ist sie nur während dieses Schritts zugänglich. Dies liegt daran, dass jeder Schritt eine eigene Hülle darstellt.
In separaten sh Dateien können Sie über ihren jeweiligen Namen in Großbuchstaben auf Eingabevariablen der Aktion zugreifen. Zum Beispiel:
inputs:
package_manager:
description: "Your preference of package manager: 'npm' and 'yarn' are possible values."
required: false
default: 'npm'
${{ inputs.package_manager }}sh -Datei: $PACKAGE_MANAGER env:
SOME_OTHER_NAME: ${{ inputs.package_manager }}
Wenn Sie sh Dateien schrittweise ausführen, können Sie nicht erwarten, dass jede Shell die Umgebungen gemeinsam nutzt. Beispielsweise installieren Sie in einem Schritt Abhängigkeiten in install.sh, in einem anderen Schritt erstellen Sie mit build.sh. Es wird nicht funktionieren, da installierte Bibliotheken nur für den Schritt install.sh verfügbar sind. Aus diesem Grund sind bash-files fehlgeschlagen. Ich habe GPT konsultiert, aber anscheinend gibt es keine Möglichkeit, dies zu erreichen.
