找不到Gitlab CI页面

时间:2018-10-19 19:33:08

标签: gitlab gitlab-ci gitlab-ci-runner

我将GitlabCI与基于docker并已正确注册的Gitlab Runner一起使用

这就是我使用docker和docker-compose运行跑步程序的方式

version: "3"
services: 
  gitlab_runner:
    image: gitlab/gitlab-runner:alpine-v11.3.1
    restart: always
    container_name: gitlab_runner_my_project
    environment:
      - CI_SERVER_URL=https://gitlab.com/
    volumes:
      - ./volumes/runner:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock:rw

这是我的跑步者配置

concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "runner for my project"
  url = "https://gitlab.com/"
  token = "my-token"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "docker:stable-dind"
    privileged = true
    disable_cache = true
    pull_policy = "if-not-present"
    volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
    shm_size = 0
    run_untagged = true
  [runners.cache]
    Type = "s3"
    Path = "cache"
    Shared = true
    [runners.cache.s3]
      ServerAddress = "s3.amazonaws.com"
      AccessKey = "AWSkey"
      SecretKey = "AWSsecret"
      BucketName = "grcache"
      Insecure = false

使用以下代码,我可以运行测试,覆盖率,部署并按预期发布带有覆盖率报告的Page。

stages:
  - test
  - deploy

test:
  image: ruby:2.5.1
  tags:
    - my_tag
  stage: test
  services:
    - mongo:3.6.3
  variables:
    RAILS_ENV: test
    MONGODB_URI: ...
  before_script:
    - bundle install
  script:
    - bundle exec rspec spec/
  artifacts:
    paths:
      - coverage/*

staging_deploy:
    .
    .
    .

pages:
  image: alpine:latest
  tags:
    - my_tag
  stage: deploy
  dependencies:
    - test
  script:
    - cp -r coverage/ public/
  artifacts:
    paths:
      - public
    expire_in: 30 days
  only:
    - test-coverage

该测试在覆盖率以及“部署”和“发布”页面方面都运行良好。下一张图片显示Pages作业的日志。

这些是管道中显示的作业。

enter image description here

enter image description here

当我访问项目的“页面”部分时,一切看起来都很好。

enter image description here

但是当我想访问该页面时。 BOOOMMMMM

enter image description here

2 个答案:

答案 0 :(得分:0)

为什么要在coverage路径的末尾添加一个星号?我想也许git无法跟踪某些文件或整个目录coverage。在这种情况下,从测试阶段更改存储的工件路径可能会有所帮助:

artifacts:
  untracked: true
  paths:
    - coverage/

仅出于快速脏调试的目的,您始终可以在.gitlab-ci.yml中添加一些脚本,以查看复制操作前后相关目录中的内容:

script:
  - ls -al
  - ls -al coverage
  - ls -al public
  - cp -r coverage/ public/
  - ls -al coverage
  - ls -al public

这可能会为问题提供一些启示。您的.gitlab-ci.yml看起来不错。

编辑:正如您所说,这可能是权限问题。我怀疑这是否会有所帮助,因为此public目录是工件,权限对此不重要。但是只是检查一下您是否可以修改其权限:

script:
  - chmod -R 755 public

答案 1 :(得分:0)

您可以通过检查环境变量来检查实际页面的URL:

pages:
  ...
  script:
    - ... others scripts
    - echo $CI_PAGES_URL
  artifacts:
    paths:
      - public