google gemini帮我解决qdb-350ec8.gitlab.io不能公开访问的问题

 访问https://gitlab.com/briteming/qdb/edit ，

在'Visibility, project features, permissions'那行，Project visibility设为public,

勾选 Users can request access，其他默认的选项值不要动，然后点击底部的save changes按钮。qdb-350ec8.gitlab.io就能公开访问了。

相关帖子： https://briteming.blogspot.com/2026/09/gitlab-pages.html

如何将静态网站根目录的内容推送到 GitLab Pages

与普通 Git 推送有所不同：GitLab Pages 必须依赖 .gitlab-ci.yml 自动化构建文件，且网页文件必须存放在构建产物文件夹（通常命名为 public）中，GitLab 才会自动将其部署发布。

以下是将本地的静态网站根目录推送到 GitLab Pages 的最简流程：

第一步：在项目根目录里，创建 CI/CD 配置文件.

在包含 index.html 的本地网站根目录下，新建一个名为 .gitlab-ci.yml 的文件，并写入以下内容：

pages:
  stage: deploy
  script:
    - mkdir -p public
    # 将根目录下除 public 以外的所有静态文件复制到 public 文件夹中
    - cp -r $(ls -A | grep -v '^public$') public/
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

原理说明：GitLab Pages 要求最终对外展示的文件存放在名为 public 的产物（artifacts）目录中。上面的脚本会在 GitLab 服务器端自动创建 public 目录并将根目录的文件复制进去，不需要改动你本地的文件结构。

第二步：提交并推送根目录内容在终端中依次运行以下命令，将代码推送到 GitLab：

1.初始化与添加文件：确认已在项目根目录下，将所有文件（包括新建的 .gitlab-ci.yml）加入 Git：
git init .
git add .
git commit -m "xx"

2.关联 GitLab 远程仓库：先在 GitLab.com/your-username/上新建一个空仓库，我新建的空仓库是qdb, 仓库地址是
https://gitlab.com/briteming/qdb
复制 SSH 或 HTTPS 仓库链接并关联：
git remote set-url origin https://gitlab.com/你的用户名/你的仓库名
（我的情况为git remote set-url origin https://gitlab.com/briteming/qdb)

3.推送至 GitLab：将代码推送到主分支：
git branch -m main

git push -f origin main

演示静态网站的网址：https://briteming.gitlab.io/qdb,会跳转到

https://qdb-350ec8.gitlab.io/ (要登录gitlab.com后，才能打开该网站。有点奇怪）

验证部署:

    推送完成后，打开 GitLab仓库页面，进入侧边栏的 Build > Pipelines（构建 > 流水线）。

    等待名为 pages 的任务运行完毕（显示绿色勾标志）。

    进入侧边栏的 Deploy > Pages。

--------------------------------------------

 多亏了google gemini的指点，才搞定。真不容易，看下面的内容，看半天，没看明白：

 https://docs.gitlab.com/user/project/pages/
https://docs.gitlab.com/user/project/pages/introduction/

 https://about.gitlab.com/blog/gitlab-pages-setup/
https://docs.gitlab.com/ci/environments/deployments/

( https://docs.gitlab.com/user/ssh/)

代码质量检查工具SonarQube 的配置

 （https://docs.sonarsource.com/sonarqube/latest/）

前言

最近负责公司一部分项目的代码仓库管理及 code review 等，用到了 SonarQube 这一代码质量检查工具，通过集成 GitLab CI，能够实现在每次合并请求/提交时自动执行代码质量检查并输出检测报告。

本文记录了通过 GitLab 仓库导入项目的配置全流程，以便其他项目配置时参考。

SonarQube 项目配置

项目面板

 SonarQube 项目面板如上图所示，会以评级的方式对项目代码质量进行分析。每次进行代码分析后，可以很直观地对代码进行多维度的分析，在合并分支前，提交人员可参照分析结果对代码进行修改完善，减少了代码审阅人员不必要的工作量。

点击具体指标则可以深入代码文件对检测出的问题进行标识，为人工 code review 提供了有效参照。

项目配置

 点击右上角「新增项目」，可选择不同的分析方式，支持 Jenkins, GitLab CI 及 GitHub Actions 等常用代码仓库自动化工作流方式，本文将主要说明 GitLab CI 的配置方式。

选择 GitLab CI 后，选择关联 GitLab 帐号中的项目仓库，进行后续配置。

 以 Go 项目为例，首先，我们需要按照提示手动创建 sonar-project.properties 文件并粘贴配置信息。

然后需要为项目创建 Token，并在 GitLab 中 「设置」-「CI/CD」-「变量」配置选项中填写 Token 及 URL 变量值。

CI 配置

进行基本项目配置后，需要通过 .gitlab-ci.yml 配置 GitLab CI 工作流，我的配置如下图所示：

我主要设置了当仓库进行合并请求时，如 src 目录下的代码有改变，则执行 testing 流水线，通过 SonarQube 进行代码质量检查。

GitLab CI 中还可以添加部署等脚本，与 SonarQube 工具配合使用，以实现工作流的优化。项目的 CI 脚本需要添加相应的 Runner 运行。

当检测到合并请求时，sonarqube-check 会被触发执行，最终返回执行结果。

此时点开 SonarQube 中项目的页面，则已经有了分析信息，本次代码质量检查完成。

总结

以上就是对 GitLab 仓库中现有 Go 项目配置 SonarQube 代码质量检查工具的全流程。代码质量自动化检查是开发运维规范流程中重要的环节，尤其是在团队项目中，好的规范有助于工作流的优化，提升项目的整体质量。

后续也将会对工作中用到的开发运维规范开源工具配置与使用进行记录，如有错漏，敬请交流指正。

参考资料

1. SonarQube Document