smalljs$molCerca⌘ KDocumentazionePlaygroundConfrontoEcosistemaInformazioniIT
DeploymentGetting StartedIntroduzioneModello mentalePer iniziareDa TypeScript a view.treeStruttura del progettoStrumentiEssentialsInstallazioneVisteStato e reattivitàRoutingRenderingTestingDeploymentRisoluzione dei problemiDataRecupero datiSchemi di datiGiper BazaMoreVetrinaDa React, Vue e SvelteRicettarioAdvancedPluginMetadati del moduloOfflineViste fantasmaAboutFAQTeamReleaseAPI$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

Deployment

Un'app $mol compilata è una cartella di file statici. Nessun server da tenere acceso, nessun processo Node da mantenere vivo, nessun adattatore da scegliere: ciò che ospita una cartella ospita l'app.

Cosa metti in produzione

La build scrive tutto nella cartella -/ del modulo:1my/hello/-/2├── index.html riscritto per il percorso di pubblicazione3├── web.js tutta l'app, un file solo4├── web.css5├── web.locale=en.json uno per lingua6├── manifest.json7└── … tutto ciò che una direttiva `deploy` ha copiato dentroQuella cartella è il sito. Servila da un qualsiasi host statico e l'app funziona.Tutto il resto in my/hello/ è sorgente, e -/ è generata: il .gitignore del workspace ignora -*, così il risultato della build non finisce mai nella storia del progetto. Sul web ci arriva dal ramo di deploy.

In breve

Il workflow lo scrive lo scaffolder, quindi un progetto nuovo si pubblica al push:1npx create-view-tree-lsp my/hello2git push.github/workflows/deploy.yml compila il modulo e spinge my/hello/-/ sul ramo gh-pages. GitHub lo serve appena Settings → Pages → Source è su Deploy from a branch con gh-pages — che è poi il valore predefinito di un repository in cui quel ramo esiste. Se l'URL risponde 404, è la prima impostazione da controllare.Il sito vive poi su https://<user>.github.io/<repo>/.

Cosa fa davvero il workflow

Lo reggono due action, e ognuna prende un paio di input:1- uses: hyoo-ru/mam_build@master22 with:3 package: "my/hello" # la cartella da compilare, relativa al workspace4 modules: "app" # quali moduli al suo interno5 6- uses: hyoo-ru/gh-deploy@v4.4.17 if: github.ref == 'refs/heads/main'8 with:9 folder: "my/hello/app/-"mam_build monta il workspace MAM attorno al tuo pacchetto, risolve i token $name del codice nei repository che li contengono, e compila. Non gli serve né un lockfile né un passo npm install: l'elenco delle dipendenze è il registro in .meta.tree, come racconta Struttura del progetto.gh-deploy committa la cartella compilata su gh-pages. target-folder la mette in una sottocartella invece che nella radice: è così che nasce l'anteprima di un ramo: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 }}Modifica questa pagina su GitHubÈ stato utile?SìNoPrecedenteTestingSuccessivoRisoluzione dei problemiIn questa paginaCosa metti in produzioneIn breveCosa fa davvero il workflowUn file di cui il deploy ha bisognoFile che devono stare nella radice del sitoLink diretti su un host staticoControllare prima di pushareOltre GitHub Pages
Type to search the documentation.