[[431613]]

本文轉(zhuǎn)載自微信公眾號「精益碼農(nóng)」，作者有態(tài)度的馬甲。轉(zhuǎn)載本文請聯(lián)系精益碼農(nóng)公眾號。

在前公司，我根據(jù)主流的git flow 給團隊搭建了一套devops流程，運行在 docker & k8s上。

在現(xiàn)代devops流程中，一般推薦使用git分支名或者git tag作為鏡像的tag名。

在實際操作中， 我遇到了一個流程阻塞。

根據(jù)git flow的規(guī)范，我們一般會打出feature/xxx, fix/issue234, release/x.x.x 這樣的分支名， 當(dāng)然我們還會產(chǎn)生x.y.z 這樣的git tag名。

但是docker build -t產(chǎn)生鏡像tag的規(guī)定，除了-,_,.鏡像tag不允許使用其他特殊字符

A tag name must be valid ASCII and may contain lowercase and uppercase letters, digits, underscores, periods and dashes. A tag name may not start with a period or a dash and may contain a maximum of 128 characters

我當(dāng)時是讓團隊小伙伴不要打出含有 /的分支名， 改用其他，如上圖中所示的release-1.0.0等，但是我始終覺得不是一個常規(guī)操作，因為這破壞了一以貫之的git flow命名規(guī)范，而且需要在團隊內(nèi)做技術(shù)性約束。

當(dāng)git flow分支命名與docker image tag分支有沖突，該怎么辦?

面向谷歌編程，面向Stackoverflow[1]編程啊。

01腳本替換

在Gitlab-ci流程中，我們使用shell腳本將特殊字符替換：

docker build . -t image_name:$CI_COMMIT_REF_NAME | sed 's/[^a-zA-Z0-9]/-/g') 

CI_COMMIT_REF_NAME: The branch or tag name for which project is built. 

02gitlab-ci內(nèi)置變量CI_COMMIT_REF_SLUG

可能Gitlab-ci早就關(guān)注到這個問題， 在9.0 給出了一個CI_COMMIT_REF_SLUG變量。

CI_COMMIT_REF_SLUG :CI_COMMIT_REF_NAME in lowercase, shortened to 63 bytes, and with everything except 0-9 and a-z replaced with -. No leading / trailing -. Use in URLs, host names and domain names. 

很明顯，CI_COMMIT_REF_SLUG[2] 是最優(yōu)解，完美規(guī)避了gitflow branch和Docker image tag的命名沖突。

本文基本沒啥技能點， 單純記錄在Devops路上的一個小插曲，前人栽樹后人乘涼;

順便表明一個態(tài)度，希望在流暢、自然的開發(fā)流程上深耕。

后續(xù)大家有意的話，可以結(jié)合 《基于容器和K8s的 Devops 探索和落地實踐》 了解一個常規(guī)/有效/可落地的Devops流程。