smalljs$molRechercher⌘ KDocsPlaygroundComparerÉcosystèmeÀ proposFR
DéploiementGetting StartedIntroductionModèle mentalDémarrageDe TypeScript à view.treeStructure d'un projetOutillageEssentialsInstallationVuesÉtat et réactivitéRoutageRenduTestsDéploiementDépannageDataRécupération de donnéesSchémas de donnéesGiper BazaMoreVitrineDe React, Vue et SvelteRecettesAdvancedPluginsMétadonnées de moduleHors-ligneVues fantômesAboutFAQÉquipeVersionsAPI$mol_button_major$mol_button_minor$mol_string$mol_number$mol_text$mol_paragraph$mol_list$mol_row$mol_link$mol_check$mol_switch$mol_select$mol_scroll$mol_page$mol_pick

Déploiement

Une application $mol compilée est un dossier de fichiers statiques. Aucun serveur à faire tourner, aucun processus Node à maintenir en vie, aucun adaptateur à choisir : ce qui héberge un dossier héberge l'application.

Ce que vous déployez

La compilation écrit tout dans le dossier -/ du module :1my/hello/-/2├── index.html réécrit pour le chemin de déploiement3├── web.js toute l'application, un seul fichier4├── web.css5├── web.locale=en.json un par langue6├── manifest.json7└── … tout ce qu'une directive `deploy` a copiéCe dossier est le site. Servez-le depuis n'importe quel hébergement statique et l'application tourne.Tout le reste dans my/hello/ est du source, et -/ est généré : le .gitignore de l'espace de travail ignore -*, donc le résultat de la compilation n'entre jamais dans l'historique du projet. Il arrive sur le web par la branche de déploiement.

La version courte

Le générateur écrit le workflow, donc un nouveau projet se publie au push :1npx create-view-tree-lsp my/hello2git push.github/workflows/deploy.yml compile le module et pousse my/hello/-/ sur la branche gh-pages. GitHub la sert dès que Settings → Pages → Source est sur Deploy from a branch avec gh-pages — ce qui est la valeur par défaut d'un dépôt où cette branche existe. Si l'URL renvoie un 404, c'est le premier réglage à vérifier.Le site vit alors à l'adresse https://<user>.github.io/<repo>/.

Ce que fait le workflow

Deux actions le portent, et chacune prend deux entrées :1- uses: hyoo-ru/mam_build@master22 with:3 package: "my/hello" # le dossier à compiler, relatif à l'espace de travail4 modules: "app" # quels modules à l'intérieur5 6- uses: hyoo-ru/gh-deploy@v4.4.17 if: github.ref == 'refs/heads/main'8 with:9 folder: "my/hello/app/-"mam_build déploie l'espace de travail MAM autour de votre paquet, résout les jetons $name de votre code en dépôts qui les contiennent, et compile. Il n'a besoin ni de fichier de verrouillage ni d'étape npm install : la liste des dépendances, c'est le registre dans .meta.tree, comme le décrit Structure du projet.gh-deploy commite le dossier compilé sur gh-pages. target-folder le place dans un sous-dossier plutôt qu'à la racine : c'est ainsi qu'on obtient un aperçu de branche :1- name: Deploy feature branch2 if: startsWith(github.ref, 'refs/heads/feature/')3 uses: hyoo-ru/gh-deploy@v4.4.14 with:5 folder: "my/hello/app/-"6 target-folder: ${{ github.ref_name }}Modifier cette page sur GitHubÉtait-ce utile ?OuiNonPrécédentTestsSuivantDépannageSur cette pageCe que vous déployezLa version courteCe que fait le workflowUn fichier dont le déploiement a besoinLes fichiers qui doivent être à la racineLiens profonds sur un hébergement statiqueVérifier avant de pousserAu-delà de GitHub Pages
Type to search the documentation.