ci(deploy): add workflow for CDN deployment#1746
ci(deploy): add workflow for CDN deployment#1746chilingling merged 4 commits intoopentiny:developfrom
Conversation
WalkthroughA new GitHub Actions workflow automates building and deploying a designer-demo package to Huawei Cloud OBS. The workflow includes secret verification, version-stamped builds with environment configuration, artifact management, and conditional deployment to both versioned and latest paths. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/deploy-cdn.yml:
- Around line 153-155: The obsutil upload commands (the obsutil cp invocation
that uploads ./designer-demo/dist to obs://${{ env.HUAWEI_CLOUD_BUCKET }}/${{
needs.build.outputs.obs-path }}) are using the -flat flag which flattens the
Vite output and breaks asset paths; remove the -flat flag from that obsutil cp
call (and the other similar invocation around the other occurrence) so the -r -f
options remain but directory hierarchy is preserved, ensuring assets like
assets/js/ and assets/css/ retain their nested paths.
- Around line 140-145: In the "Install obsutil" step, add SHA-256 checksum
verification before extracting or installing obsutil: fetch the official
checksum (or store the expected hash in a secret/variable), compute the
downloaded file's SHA-256 (obsutil.tar.gz) and compare it (e.g., using sha256sum
-c or echo "<expected> obsutil.tar.gz" | sha256sum -c -), and fail the job if
the checksum does not match; only run tar -xzf, chmod and sudo mv (the
obsutil_linux_amd64_*/obsutil install flow) after successful verification to
ensure integrity.
🧹 Nitpick comments (2)
.github/workflows/deploy-cdn.yml (2)
12-16: Scope Huawei Cloud secrets to deploy-cdn only.Top-level
envexposes secrets to all jobs (including build and third-party actions). Scoping reduces blast radius without affecting functionality.🔐 Proposed change (move secrets to deploy job)
-env: - HUAWEI_CLOUD_AK: ${{ secrets.HUAWEI_CLOUD_AK }} - HUAWEI_CLOUD_SK: ${{ secrets.HUAWEI_CLOUD_SK }} - HUAWEI_CLOUD_ENDPOINT: ${{ secrets.HUAWEI_CLOUD_ENDPOINT }} - HUAWEI_CLOUD_BUCKET: ${{ secrets.HUAWEI_CLOUD_BUCKET }}deploy-cdn: + env: + HUAWEI_CLOUD_AK: ${{ secrets.HUAWEI_CLOUD_AK }} + HUAWEI_CLOUD_SK: ${{ secrets.HUAWEI_CLOUD_SK }} + HUAWEI_CLOUD_ENDPOINT: ${{ secrets.HUAWEI_CLOUD_ENDPOINT }} + HUAWEI_CLOUD_BUCKET: ${{ secrets.HUAWEI_CLOUD_BUCKET }}
48-50: Prevent overlapping deploys to the same CDN paths.Concurrency is applied only to the build job, so multiple manual runs can still overlap during
deploy-cdnand race on thelatestpath. Consider applying concurrency to the deploy job (or workflow-level) to serialize uploads.♻️ Suggested adjustment
deploy-cdn: + concurrency: + group: deploy-cdn + cancel-in-progress: trueAlso applies to: 127-129
English | 简体中文
PR
ci: 支持部署设计器到cdn(解决部分未使用代理用户使用github page可能访问不通问题)
使用:

测试&验证:

成功部署:
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Background and solution
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information