Déployez votre application Vite sur les pages Github, en un coup d'œil.
vite
comme outil build
. Vue, React, Svelte... À vous de choisir ! - name: Vite Github Pages Deployer
uses: skywarth/[email protected]
Vous pouvez utiliser cette action simplement en l'ajoutant de manière appropriée aux fichiers yaml
de votre action.
Assurez-vous de placer cette étape après votre étape de « paiement ».
- name : Vite Github Pages Deployer
uses : skywarth/[email protected]
id : deploy_to_pages
Vous devez placer la section environnement juste avant les steps
. Cela permet la publication de l'environnement, sous l'onglet environnements.
environment :
name : demo
url : ${{ steps.deploy_to_pages.outputs.github_pages_url }}
Vous devez définir l'autorisation appropriée pour l'action afin de libérer avec succès l'environnement et l'artefact. Si vous ne le faites pas, vous risquez de recevoir des erreurs d'autorisation.
La déclaration d'autorisation peut être placée n'importe où avant la section jobs:
:.
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions :
contents : read
pages : write
id-token : write
Si vous ne savez pas quoi faire, quelles sont les actions ou où placer les morceaux de code dans la section d'utilisation, procédez comme suit :
./.github/workflows/vite-github-pages-deploy.yml
. Donc, en substance, créez un dossier .github
à la racine de votre projet et créez-y un fichier yml
.master
, ou de votre prochaine exécution manuelle à partir de l'onglet actions, cette action s'exécutera et votre projet sera déployé sur les pages github. 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
Vous voulez le voir en action ? Bien sûr, rendez-vous sur ce projet vue pour le voir en direct : https://github.com/skywarth/country-routing-algorithm-demo-vue
public_base_path
(facultatif)Taper | Défaut | Exemples de valeurs |
---|---|---|
string | /{your-repo-name} OU / si vous avez CNAME | /my-vite-project |
Chaîne de chemin de base publique pour Vite, cela affecte les liens de routage, d'historique et d'actifs. Assurez-vous de fournir de manière appropriée puisque GitHub Pages stocke votre application dans un répertoire sous un sous-domaine. Si vous envisagez de déployer sur une plateforme alternative telle que Vercel, vous devez simplement fournir /
.
Dans des circonstances normales, vous n'avez pas besoin de fournir/remplacer ce paramètre, l'action le définira de manière appropriée sur le nom de votre dépôt.
public_base_path
est résolu :public_base_path
est fourni, il sera utilisé malgré tout.public_base_path
n'est PAS fourni :CNAME
pour la configuration du domaine personnalisé des pages GitHub, la valeur par défaut public_base_path
sera résolue en /
CNAME
, la valeur par défaut public_base_path
sera résolue en /{your-repo-name}
Voir la suggestion pour l'extension CNAME ici
Merci à Greg Sadetsky pour sa proposition sur la valeur par défaut alternée de cette entrée. Nous sommes également reconnaissants pour sa collaboration pour expliquer la configuration du domaine personnalisé des pages GitHub et la phase de test de ces modifications.
build_path
(facultatif)Taper | Défaut | Exemples de valeurs |
---|---|---|
string | ./dist | - ./deploy - ./dist/browser |
Quel dossier souhaitez-vous que votre page GitHub utilise comme répertoire racine, après le processus de construction. Il s'agit simplement du répertoire de sortie de votre build tel que ./dist
. Si votre configuration vite
est exportée vers un dossier autre que ./dist
, vous devez la transmettre en paramètre.
install_phase_node_env
(facultatif)Taper | Défaut | Exemples de valeurs |
---|---|---|
string | dev | dev - production - staging - test - my-little-pony-env |
Environnement de nœud qui sera utilisé pour l'installation des dépendances. Il est impératif que vous utilisiez un environnement qui a « vite » comme dépendance . Généralement et naturellement, cet env est dev
.
Si vous ne fournissez pas de NODE_ENV qui a vite
comme dépendance (vérifiez votre package.json), vous recevrez sh: 1: vite: not found
pendant la phase de construction.
build_phase_node_env
(facultatif)Taper | Défaut | Exemples de valeurs |
---|---|---|
string | production | dev - production - staging - test - my-little-pony-env |
Environnement de nœud qui sera utilisé pour la phase de build. Vous pouvez fournir n'importe quelle valeur NODE_ENV valide pour cela, car les versions de nœuds ont tendance à changer pour différents environnements (par exemple : vous masquez les fonctionnalités de débogage de la production).
artifact_name
(facultatif)Taper | Défaut | Exemples de valeurs |
---|---|---|
string | github-pages | - what-a-cool-artifact - ah-yes-ze-artifact |
Nom souhaité pour l’artefact exposé. Ce nom est visible dans le travail et utilisé comme nom des artefacts.
package_manager
(facultatif)Taper | Défaut | Exemples de valeurs |
---|---|---|
string | npm | - npm - yarn |
Indiquez le gestionnaire de paquets de préférence. Il sera utilisé pour installer les dépendances et construire le dist
. Par exemple, si vous préférez/utilisez yarn
comme gestionnaire de paquets pour le projet, vous pouvez alors transmettre package_manager: 'yarn'
comme entrée qui sera ensuite utilisée comme yarn install
et yarn build
.
debug_mode
(facultatif)Taper | Défaut | Exemples de valeurs |
---|---|---|
string | 'false' | - 'true' - 'false' |
Contrôle le mode de débogage, la chaîne, 'true'
est activé. Lorsqu'il est activé, il affichera certaines informations sur certaines étapes. Principalement utilisé pour le développement, mais utilisez-le à votre guise pour inspecter votre environnement et vos variables.
github_pages_url
Taper | Exemples de valeurs |
---|---|
string | - 'https://skywarth.github.io/country-routing-algorithm-demo-vue/' |
Cette valeur de sortie doit être utilisée pour acquérir l'URL des pages Github après le déploiement. Il est accessible comme ceci : ${{ steps.deploy_to_pages.outputs.github_pages_url }}
(deploy_to_pages est l'identifiant de l'étape que vous exécutez Vite Github Pages Deployer).
Il devrait être utilisé comme moyen de publier l'environnement pendant le travail, comme ceci :
environment:
name: demo
url: ${{ steps.deploy_to_pages.outputs.github_pages_url }}
Voir un exemple de flux de travail pour comprendre comment utiliser cette sortie
Erreur : Environment URL '' is not a valid http(s) URL, so it will not be shown as a link in the workflow graph.
Cause : La déclaration d'environnement est manquante dans l'action, vous devez l'ajouter à votre fichier yaml
d'action afin à la fois de résoudre l'erreur/l'avertissement et d'afficher l'environnement publié dans l'onglet environments
du référentiel.
Solution : ajoutez ce qui suit à votre action :
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
doit être identique à l' id
de l'étape pendant laquelle vous exécutez le Vite GitHub pages deployer
. Voir l'exemple de flux de travail pour plus de détails.
GITHUB_TOKEN
Erreur : Error: Ensure GITHUB_TOKEN has permission "id-token: write".
Cause : L'autorisation n'a pas été définie comme indiqué dans la section d'utilisation. Si les autorisations appropriées ne sont pas accordées à l'action, elle ne pourra pas créer d'artefacts ni créer d'environnements.
Solution : ajoutez le code suivant concernant les autorisations à votre fichier d'action yaml
.
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
Consultez l’exemple de flux de travail si vous ne savez pas où le placer.
package-lock.json
n'est pas présent lors de l'utilisation npm
comme préférence du gestionnaire de packages. Erreur : The
command can only install with an existing package-lock.json...
Cause : Si la préférence d'entrée package_manager
est définie sur npm
(ou par défaut, non attribuée), les dépendances seront installées à l'aide de npm ci
qui utilise package-lock.json
. Dans ce cas, assurez-vous que package-lock.json
est présent à la racine de votre projet.
Solution : ajoutez votre fichier package-lock.json
à votre projet. S'il se trouve dans le répertoire mais n'apparaît pas dans le référentiel, vérifiez votre fichier gitignore et supprimez-le de gitignore. Alternativement, vous pouvez définir yarn
comme gestionnaire de paquets préféré pour l'installation des dépendances via l'entrée du paramètre package_manager
de l'action.
bash-files
) bash-files
)Avez-vous besoin de quelque chose, cette action ne répond-elle pas à vos attentes ou manque-t-elle de certains avenirs qui vous empêchent de l'utiliser ? Ouvrez un problème et nous l'ajoutons à la feuille de route/TODO. Les contributions sont les bienvenues.
${{github.action_path}}
: vous donne le répertoire de cette action elle-même.
${{ github.workspace }}
: Vous donne le répertoire du projet (Ex : /home/runner/work/country-routing-algorithm-demo-vue/country-routing-algorithm-demo-vue)
Lorsque vous importez un fichier sh dans le shell bash, il n'est accessible qu'à cette étape. Cela est dû au fait que chaque étape est une coquille en soi.
Dans des fichiers sh
séparés, vous pouvez accéder aux variables d'entrée de l'action par leur nom respectif en majuscule. Par exemple:
inputs:
package_manager:
description: "Your preference of package manager: 'npm' and 'yarn' are possible values."
required: false
default: 'npm'
${{ inputs.package_manager }}
sh
: $PACKAGE_MANAGER
env:
SOME_OTHER_NAME: ${{ inputs.package_manager }}
Si vous exécutez les fichiers sh
par étapes, ne vous attendez pas à ce que chaque shell partage les environnements. Par exemple, dans une étape, vous installez les dépendances dans install.sh, dans une autre étape, vous construisez par build.sh. Cela ne fonctionnera pas car les bibliothèques installées ne sont disponibles que pour l'étape install.sh. C'est pourquoi bash-files
ont échoué, j'ai consulté GPT mais apparemment il n'y a aucun moyen d'y parvenir.