Vite アプリケーションを Github Pages にデプロイする様子が一目で分かります。
vite
build
ツールとして使用する限り、任意のフロントエンド フレームワークで使用できます。 Vue、React、Svelte...何でもいいです! - name: Vite Github Pages Deployer
uses: skywarth/[email protected]
このアクションは、アクションのyaml
ファイルに適切に追加するだけで使用できます。
このステップは必ず「チェックアウト」ステップの後に配置してください。
- name : Vite Github Pages Deployer
uses : skywarth/[email protected]
id : deploy_to_pages
環境セクションはsteps
の直前に配置する必要があります。これにより、「環境」タブで環境のリリースが有効になります。
environment :
name : demo
url : ${{ steps.deploy_to_pages.outputs.github_pages_url }}
環境とアーティファクトを正常にリリースするには、アクションに適切な権限を設定する必要があります。そうしないと、権限エラーが発生する可能性があります。
権限宣言は、 jobs:
セクションの前のどこにでも配置できます。
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions :
contents : read
pages : write
id-token : write
何をすべきか、どのようなアクションであるか、または使用法セクションのどこにコード部分を配置するかがわからない場合は、次の手順に従ってください。
./.github/workflows/vite-github-pages-deploy.yml
にアクション ファイルを作成します。したがって、本質的には、プロジェクトのルートに.github
フォルダーを作成し、そこにyml
ファイルを作成します。master
ブランチへのプッシュ、またはアクション タブからの次回の手動実行で、このアクションが実行され、プロジェクトが 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
実際に動作しているところを見てみたいですか?もちろん、この vue プロジェクトにアクセスしてライブを確認してください: https://github.com/skywarth/country-routing-algorithm-demo-vue
public_base_path
(オプション)タイプ | デフォルト | 値の例 |
---|---|---|
string | /{your-repo-name} または/ CNAME がある場合 | /my-vite-project |
Vite の公開ベース パス文字列。これはルーティング、履歴、アセット リンクに影響します。 GitHub Pages はアプリをサブドメイン内のディレクトリに保存するため、必ず適切に指定してください。 Vercel などの代替プラットフォームにデプロイする予定がある場合は、単に/
指定する必要があります。
通常の状況では、このパラメータを指定/オーバーライドする必要はありません。アクションによってリポジトリ名が適切に設定されます。
public_base_path
が解決される方法は次のとおりです。public_base_path
パラメータ/入力が指定されている場合、それは関係なく使用されます。public_base_path
パラメータ/入力が指定されていない場合:CNAME
ファイルがある場合、 public_base_path
デフォルト値は/
に解決されます。CNAME
がない場合、 public_base_path
デフォルト値は/{your-repo-name}
に解決されます。 CNAME 拡張の提案については、こちらをご覧ください。
この入力の代替デフォルト値に関する提案を行った Greg Sadetsky に感謝します。また、GitHub ページのカスタム ドメイン設定とこれらの変更のテスト段階について説明する際に協力してくれたことに感謝します。
build_path
(オプション)タイプ | デフォルト | 値の例 |
---|---|---|
string | ./dist | - ./deploy - ./dist/browser |
ビルドプロセス後に、GitHub ページがルート ディレクトリとして使用するフォルダーを選択します。単に、 ./dist
などのビルド出力ディレクトリです。 vite
設定を./dist
以外のフォルダーにエクスポートする場合は、それをパラメーターとして渡す必要があります。
install_phase_node_env
(オプション)タイプ | デフォルト | 値の例 |
---|---|---|
string | dev | - dev - production - staging - test - my-little-pony-env |
依存関係のインストールに使用されるノード環境。 「vite」を依存関係として持つ環境を使用することが必須です。通常、当然のことながら、その env はdev
です。
依存関係としてvite
を持つ NODE_ENV を指定しない場合 (package.json を確認してください)、ビルド フェーズ中にsh: 1: vite: not found
を受け取ります。
build_phase_node_env
(オプション)タイプ | デフォルト | 値の例 |
---|---|---|
string | production | - dev - production - staging - test - my-little-pony-env |
ビルドフェーズに使用されるノード環境。ノードのビルドは環境ごとに変わる傾向があるため、これには有効な NODE_ENV 値を指定できます (例: デバッグ機能を本番環境から非表示にする)。
artifact_name
(オプション)タイプ | デフォルト | 値の例 |
---|---|---|
string | github-pages | - what-a-cool-artifact - ah-yes-ze-artifact |
公開されたアーティファクトの任意の名前。この名前はジョブに表示され、アーティファクト名として使用されます。
package_manager
(オプション)タイプ | デフォルト | 値の例 |
---|---|---|
string | npm | npm - yarn |
優先するパッケージマネージャーを指定します。これは、依存関係のインストールとdist
構築に使用されます。たとえば、プロジェクトのパッケージマネージャーとしてyarn
好む/使用する場合は、 package_manager: 'yarn'
入力として渡すことができ、これはyarn install
およびyarn build
として使用されます。
debug_mode
(オプション)タイプ | デフォルト | 値の例 |
---|---|---|
string | 'false' | - 'true' - 'false' |
デバッグ モードを制御する文字列。 'true'
はオンを表します。オンにすると、特定のステップで特定の情報が出力されます。主に開発に使用されますが、環境や変数を検査するために自由に使用してください。
github_pages_url
タイプ | 値の例 |
---|---|
string | - 'https://skywarth.github.io/country-routing-algorithm-demo-vue/' |
この出力値は、デプロイ後に github ページの URL を取得するために使用されます。次のようにアクセスできます: ${{ steps.deploy_to_pages.outputs.github_pages_url }}
(deploy_to_pages は、Vite Github Pages Deployer を実行するステップの ID です)。
次のように、ジョブ中に環境を公開する方法として使用されることが想定されています。
environment:
name: demo
url: ${{ steps.deploy_to_pages.outputs.github_pages_url }}
この出力の利用方法を理解するには、サンプル ワークフローを参照してください。
エラー: Environment URL '' is not a valid http(s) URL, so it will not be shown as a link in the workflow graph.
原因:アクションに環境宣言がありません。エラー/警告を解決し、リリースされた環境をリポジトリのenvironments
タブに表示するには、環境宣言をアクションyaml
ファイルに追加する必要があります。
解決策:アクションに以下を追加します。
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
名は、 Vite GitHub pages deployer
を実行するステップのid
と同一である必要があることに注意してください。詳細については、ワークフローの例を参照してください。
GITHUB_TOKEN
の権限要件が欠落しているエラー: Error: Ensure GITHUB_TOKEN has permission "id-token: write".
原因:使用法セクションに示されているように権限が設定されていませんでした。アクションに適切な権限が付与されていない場合、アーティファクトを作成したり、環境を作成したりすることはできません。
解決策:アクセス許可に関する次のコードをアクションyaml
ファイルに追加します。
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
どこに配置すればよいかわからない場合は、サンプル ワークフローを参照してください。
npm
パッケージ マネージャーの優先設定として使用する場合、 package-lock.json
存在しません。エラー: npm ci The
command can only install with an existing package-lock.json...
原因: package_manager
入力設定がnpm
(またはデフォルト、未割り当て) に設定されている場合、 package-lock.json
利用するnpm ci
使用して依存関係をインストールします。この場合、 package-lock.json
がプロジェクト ルートに存在することを確認してください。
解決策: package-lock.json
ファイルをプロジェクトに追加します。ディレクトリ内にあるのにリポジトリに表示されない場合は、gitignore ファイルを確認し、gitignore から削除します。あるいは、アクションのpackage_manager
パラメーター入力を介して、依存関係のインストール用の優先パッケージ マネージャーとしてyarn
設定することもできます。
bash-files
ブランチを参照してください) bash-files
ブランチを参照してください)何か必要なものはありますか、このアクションは期待に応えられませんか、または特定の将来性がないため使用できませんか?問題をオープンすると、それがロードマップ/TODO に追加されます。貢献は大歓迎です。
${{github.action_path}}
: このアクション自体のディレクトリを提供します。
${{ github.workspace }}
: プロジェクトのディレクトリを提供します (例: /home/runner/work/country-routing-algorithm-demo-vue/country-routing-algorithm-demo-vue)
bash シェルに sh ファイルをインポートする場合、そのステップ中にのみアクセスできます。これは、各ステップがそれ自体がシェルであるためです。
個別のsh
ファイル内では、それぞれの大文字の名前でアクションの入力変数にアクセスできます。例えば:
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 }}
sh
ファイルを段階的に実行する場合、各シェルが環境を共有することを期待しないでください。たとえば、あるステップでは install.sh に依存関係をインストールし、別のステップでは build.sh でビルドします。インストールされたライブラリは install.sh ステップでのみ使用できるため、機能しません。これがbash-files
失敗する理由です。GPT に相談しましたが、どうやらそれを達成する方法はないようです。