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 に相談しましたが、どうやらそれを達成する方法はないようです。