应用错误收集

我有一个普通的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

这可能吗？是否可以从两个不同的分支机构部署两个不同的文件夹？

您只能按照您的描述，通过master分支将更改发布到GitLab页面。但是，GitLab页面唯一要做的就是将文件放在名为public的作业的pages文件夹中。这些文件可以是您想要的任何文件，只要您设法通过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页面作业，以便即使仅更新了pages分支，也可以运行staging作业，而不能更新master分支。

有趣的是，可以从任何分支发帖，而不能从任何工作发帖。

为此，我需要进行两项更改：

我需要知道发布数据的当前状态
我需要根据当前分支更改目录

GitLab可以缓存文件夹。通常，它用于通过缓存下载的驱动程序来加快构建速度。没有理由我不能使用它来存储public文件夹。这样，当我对staging进行更改时，我会记住root应用程序的状态：

cache:
  paths:
  - public

下一个技巧是根据正在构建的当前分支将页面发布到适当的文件夹。为此，我们可以查看GitLab CI/CD Environment Variables;特别是：

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-pages

2 个答案: