vite github pages deployer
v1.4.0
将您的 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.
原因：操作中缺少环境声明，您应该将其添加到操作yaml文件中，以便解决错误/警告并在存储库的environments选项卡中显示已发布的环境。
解决方案：将以下内容添加到您的操作中：
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 （或默认，未分配），它将使用npm ci利用package-lock.json 。在这种情况下，请确保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 shell 中导入 sh 文件时，只能在该步骤中访问该文件。这是因为每个步骤都是一个独立的 shell。
在单独的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文件，请不要期望每个 shell 共享环境。例如，在一个步骤中，您在 install.sh 中安装依赖项，在另一步骤中，您通过 build.sh 构建。它不起作用，因为安装的库仅可用于 install.sh 步骤。这就是bash-files失败的原因，我查阅了 GPT 但显然没有办法实现它。
