gitlab: CI_COMMIT_BRANCH 与 CI_COMMIT_REF_NAME 区别
一次ci过程中遇到的情况记录
案发现场
我们当时执行的操作是 develop → master 分支合并
与之有关的ci
原来的
beta分支部分，此处用的是CI_COMMIT_REF_NAME就会触发 @beta/@production 2 个地方的 ci如果是希望按预期运行，将
CI_COMMIT_REF_NAME改成CI_COMMIT_BRANCH即可
build-phase-beta:
<<: *BUILD
variables:
<<: *VARIABLES
BUILD_ENV: build:beta
environment:
name: beta
rules:
- if: $CI_COMMIT_REF_NAME == "develop" || $CI_COMMIT_MESSAGE =~ /__@beta__/prod 部分
build:app:prod:
image: registry-mirrors.saybot.net/ears/puppeteer
stage: build
before_script:
- rm -rf node_modules/
- apt-get update && apt-get install -yq libpng-dev
- yarn install --development --registry=https://repos.saybot.net/repository/alo7npm
script:
- npm run build:prod
artifacts:
paths:
- dist/
expire_in: 1 week
environment:
name: prod
tags:
- docker
rules:
- if: $CI_COMMIT_REF_NAME == "master" || $CI_COMMIT_MESSAGE =~ /__@production__/区别
在合并分支时，CI_COMMIT_BRANCH 和 CI_COMMIT_REF_SLUG 的区别主要体现在对于合并请求（Merge Request）的 CI/CD 流水线中。
在合并分支时，CI_COMMIT_BRANCH 和 CI_COMMIT_REF_SLUG 的区别主要体现在对于合并请求（Merge Request）的 CI/CD 流水线中。
CI_COMMIT_BRANCH:
对于合并请求触发的 CI/CD 流水线，CI_COMMIT_BRANCH 将是目标分支（通常是合并请求目标分支上的最新提交的分支）。
如果你在一个名为 feature-branch 的分支上创建了合并请求，而目标分支是 main，那么在 CI/CD 流水线中，CI_COMMIT_BRANCH 将是 main，即目标分支的名称。
CI_COMMIT_REF_SLUG:
对于合并请求触发的 CI/CD 流水线，CI_COMMIT_REF_SLUG 仍然表示当前提交所在的分支的 URL 友好版本。
使用 CI_COMMIT_REF_SLUG 可以方便地构建用于引用分支的 URL，而不受目标分支的影响。
示例：
假设有一个名为 feature-branch 的分支，你在该分支上创建了合并请求（Merge Request），将其合并到 main 分支。在 CI/CD 流水线中：
CI_COMMIT_BRANCH 将是 main。
CI_COMMIT_REF_SLUG 仍然是 feature-branch。
这种设计使得在 CI/CD 流水线中能够方便地获取有关当前操作的信息，包括合并请求的目标分支。