相关疑难解决方法(0)

这个答案通过@joki到前面的问题表明，它可以通过给浏览的文物公开网址部署在GitLab回购来动态环境中的每个活跃的分支。

用mkdocs 材料项目尝试这个，我发现了两个问题。

首先，如果 GitLab 存储库在一个组或一个子组中，则.gitlab-ci.yml文件中的 URL需要更像这样：

    environment:
        name: review/$CI_COMMIT_REF_NAME
        url: "$CI_PAGES_URL/-/jobs/$CI_JOB_ID/artifacts/public/index.html"
        auto_stop_in: 1 week
    variables:
        PUBLIC_URL: "$CI_PAGES_URL/-/jobs/$CI_JOB_ID/artifacts/public/"

其次，网站内的相关链接不好用，导致404错误很多，样式文件等东西丢失。也许上面的网址是不正确的，或者也许是site_url在mkdocs.yml需要改变的东西，如：

site_url: !!python/object/apply:os.getenv ["CI_ENVIRONMENT_URL"]

然而，这些都不适合我。

可以在此处找到具有非常小的部署和审查应用程序的最小 MR 。

有没有人有 mkdocs 评论应用程序的工作配方？

我有一个在 GitLab Pages 上托管的普通 JavaScript 应用程序。最近，我一直在进行更改和错误修复，这些更改和错误修复已经破坏了网站，直到推送更改后我才注意到。

为了减少用户遇到错误的机会，我想在单独的文件夹中发布两个站点：

• 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
  - …