GitLab13.8版本CI/CD部分功能更新
基于GitLabCI/CD流水線實踐
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)
