smalljs$molSuche⌘ KDokuPlaygroundVergleichÖkosystemÜberDE
DeploymentGetting StartedEinführungMentales ModellErste SchritteVon TypeScript zu view.treeProjektstrukturWerkzeugeEssentialsInstallationViewsZustand und ReaktivitätRoutingRenderingTestenDeploymentFehlerbehebungDataDatenabrufDatenschemasGiper BazaMoreSchaufensterVon React, Vue und SvelteKochbuchAdvancedPluginsModul-MetadatenOfflineGhost-AnsichtenAboutFAQTeamReleasesAPI$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

Eine gebaute $mol-App ist ein Ordner mit statischen Dateien. Kein Server, der laufen muss, kein Node-Prozess, den man am Leben hält, kein Adapter, den man auswählt: was einen Ordner hostet, hostet die App.

Was Sie ausliefern

Der Build schreibt alles in den Ordner -/ des Moduls:1my/hello/-/2├── index.html auf den Auslieferungspfad umgeschrieben3├── web.js die ganze App, eine Datei4├── web.css5├── web.locale=en.json eine pro Sprache6├── manifest.json7└── … alles, was eine `deploy`-Direktive hineinkopiert hatDieser Ordner ist die Website. Von jedem statischen Host ausgeliefert, läuft die App.Alles andere in my/hello/ ist Quellcode, und -/ ist generiert: die .gitignore des Workspace ignoriert -*, also landet das Build-Ergebnis nie in der Historie des Projekts selbst. Ins Netz kommt es über den Deploy-Branch.

Die kurze Fassung

Den Workflow schreibt der Scaffolder, also veröffentlicht ein neues Projekt beim Push:1npx create-view-tree-lsp my/hello2git push.github/workflows/deploy.yml baut das Modul und pusht my/hello/-/ in den Branch gh-pages. GitHub liefert diesen Branch aus, sobald unter Settings → Pages → Source Deploy from a branch mit gh-pages steht — und genau das ist die Voreinstellung eines Repositorys, in dem ein solcher Branch existiert. Antwortet die URL mit 404, ist das die erste Einstellung, die man prüft.Die Website liegt dann unter https://<user>.github.io/<repo>/.

Was der Workflow tatsächlich tut

Zwei Actions tragen ihn, und beide nehmen ein paar Eingaben:1- uses: hyoo-ru/mam_build@master22 with:3 package: "my/hello" # der zu bauende Ordner, relativ zum Workspace4 modules: "app" # welche Module darin5 6- uses: hyoo-ru/gh-deploy@v4.4.17 if: github.ref == 'refs/heads/main'8 with:9 folder: "my/hello/app/-"mam_build baut den MAM-Workspace um Ihr Paket herum auf, löst die $name-Tokens aus Ihrem Code in die Repositorys auf, die sie enthalten, und baut. Es braucht keine Lockfile und keinen npm install-Schritt: die Abhängigkeitsliste ist die Registry in .meta.tree, wie Projektstruktur beschreibt.gh-deploy committet den gebauten Ordner nach gh-pages. target-folder legt ihn statt ins Wurzelverzeichnis in einen Unterordner — so entsteht eine Branch-Vorschau: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 }}Diese Seite auf GitHub bearbeitenWar das hilfreich?JaNeinZurückTestenWeiterFehlerbehebungAuf dieser SeiteWas Sie ausliefernDie kurze FassungWas der Workflow tatsächlich tutEine Datei, die der Deploy brauchtDateien, die im Wurzelverzeichnis liegen müssenDeep Links auf einem statischen HostVor dem Push prüfenJenseits von GitHub Pages
Type to search the documentation.