Gitlab版本升级GitLab12.9 >12.10.14 > 13.0.0 >13.8.4
https://docs.gitlab.com/omnibus/update/gitlab_13_changes.html
https://forum.gitlab.com/t/omnibus-upgrade-from-12-10-6-to-13-0-6/38737/3
https://forum.gitlab.com/t/packaged-postgresql-error-after-update-from-12-7-to-13/39451
unning handlers:
Running handlers complete
Chef Infra Client finished, 441/1538 resources updated in 03 minutes 19 seconds
gitlab Reconfigured!
Checking for an omnibus managed postgresql: OK
Checking if postgresql['version'] is set: OK
Checking if we already upgraded: NOT OK
Checking for a newer version of PostgreSQL to install
Upgrading PostgreSQL to 12.5
Checking if PostgreSQL bin files are symlinked to the expected location: OK
cp /opt/gitlab/embedded/service/gitlab-rails/public/deploy.html /opt/gitlab/embedded/service/gitlab-rails/public/index.html
Toggling deploy page: OK
Toggling services:ok: down: alertmanager: 1s, normally up
ok: down: gitaly: 1s, normally up
ok: down: gitlab-exporter: 0s, normally up
ok: down: gitlab-pages: 1s, normally up
ok: down: grafana: 0s, normally up
ok: down: logrotate: 0s, normally up
ok: down: postgres-exporter: 1s, normally up
ok: down: prometheus: 0s, normally up
ok: down: redis-exporter: 1s, normally up
ok: down: sidekiq: 1s, normally up
ok: down: sshd: 0s, normally up
Toggling services: OK
Running stop on postgresql:ok: down: postgresql: 0s, normally up
Running stop on postgresql: OK
Symlink correct version of binaries: OK
Creating temporary data directory: OK
Initializing the new database: OK
13.8新特性(CI/CD)
使用退出码控制作业的状态
语句：allow_failure:exit_codes
使用allow_failure:exit_codes动态控制作业是否应该允许失败。您可以列出哪些退出代码不被视为失败。该作业因任何其他退出代码而失败。
test_job_1:
script:
- echo "Run a script that results in exit code 1. This job fails."
- exit 1
allow_failure:
exit_codes: 137
test_job_2:
script:
- echo "Run a script that results in exit code 137. This job is allowed to fail."
- exit 137
allow_failure:
exit_codes:
- 137
- 255
参考链接：https://docs.gitlab.com/ee/ci/yaml/README.html#allow_failureexit_codes
管道规则支持定义变量
语句：rules:variables, (13.7引入， 13.8默认启用)
可以在rules:使用variables定义特定条件的变量。
job:
variables:
DEPLOY_VARIABLE: "default-deploy"
rules:
- if: $CI_COMMIT_REF_NAME =~ /master/
variables: # Override DEPLOY_VARIABLE defined
DEPLOY_VARIABLE: "deploy-production" # at the job level.
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
IS_A_FEATURE: "true" # Define a new variable.
script:
- echo "Run script with $DEPLOY_VARIABLE as an argument"
- echo "Run another script if $IS_A_FEATURE exists"
参考链接：https://docs.gitlab.com/ee/ci/yaml/README.html#allow_failureexit_codes
Docker类型的执行器配置多个镜像拉取策略
该pull_policy参数允许您指定拉取策略列表。将按照从左到右的顺序尝试列表中的策略，直到成功进行拉取或列表用尽为止。
什么时候使用多个拉策略?
当Docker注册表不可用并且您需要提高作业弹性时，此功能很有用。如果您使用该always策略并且注册表不可用，则即使所需的镜像在本地缓存，该作业也会失败。
为了克服该问题，您可以添加在故障情况下执行的其他后备拉取策略。通过添加第二个拉取策略值if-not-present，Runner可以找到任何本地缓存的Docker镜像层。
[runners.docker]
pull_policy = ["always", "if-not-present"]
项目配置是否存储最新工件
默认情况下，永远不会删除来自最近成功作业的最新工件。如果使用expire_in来配置作业，则其工件仅在存在较新的工件时才过期。
保留最新的工件会在具有大量工作或较大工件的项目中使用大量存储空间。如果项目中不需要最新的工件，则可以禁用此行为以节省空间：
导航到设置> CI/CD>Artifact。
取消选中“将工件保留在最近成功完成的工作中”。
您可以在实例的CI/CD设置中对自管理实例上的所有项目禁用此行为 。
禁用该功能时，最新的工件不会立即过期。必须运行新的管道，最新的工件才能到期并删除。
不重复使用分支和合并
13.8 新增了两个预定义变量，可以通过变量来控制CI管道。
CI_PROJECT_CONFIG_PATH 指定项目的CI配置文件路径。
CI_OPEN_MERGE_REQUESTS 在分支和合并请求管道中可用。一个逗号分隔的列表，该列表包含最多四个使用当前分支和项目作为合并请求源的合并请求。例如: gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11。
管道配置可视化
要查看gitlab-ci.yml配置的可视化，请在项目中转到CI / CD>编辑器，然后选择“**可视化”**选项卡。可视化显示了所有阶段和作业。任何needs 关系都显示为将作业连接在一起的线，显示了执行的层次结构：
将鼠标悬停在工作上以突出其needs关系：
如果配置没有任何needs关系，则不会画线，因为每个作业仅取决于成功完成的前一阶段。
启用或禁用管道编辑器:
Feature.disable(:ci_pipeline_editor_page)
Feature.enable(:ci_pipeline_editor_page)
原文地址：https://mp.weixin.qq.com/s/wWsfcx-lMtoyGC1zi8SRMg