Gitflow branch與Docker image tag命名衝突怎麼辦?
谷歌還是比必應要好用一點。
在前公司,我根據主流的git flow 給團隊搭建了一套devops流程,執行在 docker & k8s上。
在現代devops流程中,一般推薦使用git分支名或者git tag作為映象的tag名。
在實際操作中, 我遇到了一個流程阻塞。
根據git flow的規範,我們一般會打出feature/xxx,fix/issue234,release/x.x.x 這樣的分支名, 當然我們還會產生x.y.z 這樣的git tag名。
但是docker build -t
產生映象tag的規定,除了-,_,.
映象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
我當時是讓團隊小夥伴不要打出含有 /
的分支名, 如上圖中所示的release-1.0.0
等,但是我始終覺得不是一個常規操作,因為這破壞了一以貫之的git flow命名規範,而且需要在團隊內做技術性約束。
當git flow分支命名與docker image tag分支有衝突,該怎麼辦?
面向谷歌程式設計,面向Stackoverflow程式設計啊。
策略1: 指令碼手動替換
在Gitlab-ci中,我們使用:
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.
策略2: gitlab-ci內建變數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 **是正解,後續在devops中針對git branch/git tag 可採用此ci變數。
本文基本沒啥技能點, 單純記錄在Devops路上的一個小插曲,前人栽樹後人乘涼;
順便表明一個態度,希望在流暢、自然的開發流程上深耕。
後續大家有意的話,可以結合 《基於容器和K8s的 Devops 探索和落地實踐》 瞭解一個常規/有效/可落地的Devops流程。
引用連結
[1] Stackoverflow: https://stackoverflow.com/questions/62905914/turning-a-git-branch-name-into-a-valid-docker-image-tag
[2] CI_COMMIT_REF_SLUG: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
[3] 基於容器和K8s的 Devops 探索和落地實踐: https://www.cnblogs.com/JulianHuang/p/13676065.html
本文來自部落格園,作者:{有態度的馬甲},轉載請註明原文連結:https://www.cnblogs.com/JulianHuang/p/15469639.html
歡迎關注我的原創高價值公眾號