It is recommended to add a new feature, where if a step within a job fails, the entire job still appears as green (passed) status, without affecting the actual status. The current continue-on-error statement causes the job's actual status to be incorrect, making the ${{ failure() }} statement perpetually false, i.e., always successful, which impacts the true judgment. So if: ${{ needs.sync.result == 'success' }} will always works. Sometimes a job is merely intended to fetch and check for updates. If there are no updates, commands like git will return an error. However, if we want to execute another job when there are updates, we need to determine the actual state of that job. But to ensure that the job still returns normal even without updates, we need a command statement that makes the job always appear as true without affecting the job's real execution status.
name: 🔗 自动拉取-部署
on:
repository_dispatch:
workflow_dispatch:
schedule:
- cron: "*/5 * * * *"
# 设置 GITHUB_TOKEN 的权限,以允许部署到 GitHub Pages
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: pages
cancel-in-progress: true
jobs:
sync:
runs-on: ubuntu-24.04
steps:
- name: Setting TimeZone to UTC+8
uses: szenius/set-timezone@v2.0
with:
timezoneLinux: "Asia/Shanghai"
- name: Show the timezone
run: |
date
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Update submodules
run: |
git submodule update --init --recursive --remote
git config --global user.name "ykla"
git config --global user.email "yklaxds@gmail.com"
git commit -am "同步 SEP-CN"
git push
continue-on-error: true
nothing:
needs: sync
runs-on: ubuntu-24.04
steps:
- name: Show the status
run: |
echo "无事可做"
exit 0
build:
needs: sync
if: ${{ needs.sync.result == 'success' }}
runs-on: ubuntu-24.04
name: build
steps:
- name: Setting TimeZone to UTC+8
uses: szenius/set-timezone@v2.0
with:
timezoneLinux: "Asia/Shanghai"
- name: Show the timezone
run: |
date
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0 # lastUpdated 需要
submodules: 'true'
- uses: pnpm/action-setup@v4
with:
version: latest
- name: Add swap
uses: actionhippie/swap-space@v1
with:
size: 16G
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
- name: Setup Pages
uses: actions/configure-pages@v5
- name: Install dependencies
run: pnpm install
- name: Build with VitePress
run: pnpm run docs:build
env:
NODE_OPTIONS: --max_old_space_size=16384
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: doc/.vitepress/dist
- name: Show Usage
run: |
du -h ${{ runner.temp }}/artifact.tar
du -sh doc/.vitepress/dist
du -sh doc
date
# 部署工作
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
needs: build
if: ${{ success() }}
runs-on: ubuntu-24.04
name: Deploy
steps:
- name: Setting TimeZone to UTC+8
uses: szenius/set-timezone@v2.0
with:
timezoneLinux: "Asia/Shanghai"
- name: Show the timezone
run: |
date
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
If this is done, not only will sync report an error, but the subsequent three jobs will still execute
jobs:
sync:
runs-on: ubuntu-24.04
continue-on-error: true
steps:
or
- name: Update submodules
continue-on-error: true
run: |
git submodule update --init --recursive --remote
git config --global user.name "ykla"
git config --global user.email "yklaxds@gmail.com"
git commit -am "同步 SEP-CN"
git push
- name: Show the status
if: failure()
run: |
echo "无事可做"
exit 0
It is recommended to add a new feature, where if a step within a job fails, the entire job still appears as green (passed) status, without affecting the actual status. The current
continue-on-errorstatement causes the job's actual status to be incorrect, making the${{ failure() }}statement perpetually false, i.e., always successful, which impacts the true judgment. Soif: ${{ needs.sync.result == 'success' }}will always works. Sometimes a job is merely intended to fetch and check for updates. If there are no updates, commands like git will return an error. However, if we want to execute another job when there are updates, we need to determine the actual state of that job. But to ensure that the job still returns normal even without updates, we need a command statement that makes the job always appear as true without affecting the job's real execution status.If this is done, not only will sync report an error, but the subsequent three jobs will still execute
or