我有一个普通的JavaScript应用程序，我托管在GitLab Pages上。最近，我一直在进行更改和错误修复，这些更改和错误修复一直在破坏网站，直到已经推送了更改，我才注意到。
为了减少用户接触错误的风险，我想在单独的文件夹中发布两个站点：
public/：master分公司;官方网站public/staging/：staging分支;夜间建造
我希望这些对应于两个不同的分支：master和staging
阅读 GitLab CI for GitLab Pages，听起来这甚至是不可能的。我希望我读错了。
default:
image: node:latest
test:
stage: test
script:
- npm install
- node test.js
only:
- staging
- master
staging:
stage: deploy
environment: staging
script:
- mkdir -p public/staging
- cp -r www public/staging
artifacts:
paths:
- public
only:
- staging
pages:
stage: deploy
environment: production
script:
- mkdir -p public
- cp -r www public
artifacts:
paths:
- public
only:
- master
这可能吗？是否可以从两个不同的分支部署两个不同的文件夹？
有趣的是，可以从任何分支发布，只是不能从任何工作发布。
为此，我需要进行两项更改：
- 我需要知道已发布数据的当前状态
- 我需要根据当前分支更改目录
GitLab 具有缓存文件夹的能力。通常，这用于通过缓存下载的驱动程序来加快构建速度。我没有理由不能使用它来存储public文件夹。这样当我对staging进行更改时，我会记住root应用程序的状态：
cache:
paths:
- public
下一个技巧是将页面发布到适当的文件夹，具体取决于正在构建的当前分支。为此，我们可以查看 GitLab CI/CD 环境变量;特别：
CI_COMMIT_REF_SLUG： 当前分支CI_DEFAULT_BRANCH：默认分支(主分支(
知道了这两个值，我们可以做一些bash来确定将内容写入的正确位置。
pages:
stage: deploy
script:
- dir="$CI_COMMIT_REF_SLUG"
- if [ "$CI_COMMIT_REF_SLUG" == "$CI_DEFAULT_BRANCH" ]; then dir=""; fi;
- dir="public/$dir"
- echo "Deploying to $dir"
- mkdir -p $dir
- cp -r www $dir
artifacts:
paths:
- public
only:
- staging
- master
不要忘记将页面限制为仅staging和master。
警告
我对此不满意。
我认为最好将缓存维护在完全不同的地方并在稍后阶段复制它们，但每次都完全重写公用文件夹。
随着时间的推移，当前的解决方案将逐渐变得脆弱，但基本思想是合理的。
正如您所描述的那样，您只能通过主分支将更改发布到 GitLab 页面。不过，GitLab 页面唯一要做的就是将文件放在名为pages的作业中的public文件夹中。这些文件可以是您想要的任何文件，只要您设法通过 GitLab 作业将它们发送到此文件夹即可。
你可以尝试这样的事情：
pages:
...
script:
- mkdir -p public
- cp -r www public
- git checkout origin/staging
- mkdir -p public/staging
- cp -r www public/staging
我还没有测试过这个，所以如果它不起作用，请告诉我！
如果运行 GitLab 作业，它通常具有存储库的所有 git 历史记录。不过，在 git 和 GitLab 中都有更改此设置，因此您必须确保始终将所有 git 历史记录获取到pages作业中。如果你有一个尚未添加到 git 的文件夹，比如public，当你签出另一个分支时，git 不应该改变其中的任何内容。
我认为您还应该能够使用计划设置 GitLab 页面作业，以便即使只更新了staging分支，而不是更新了master分支，也可以运行pages作业。