在前公司，我根据主流的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]编程啊。
01
脚本替换
在Gitlab-ci流程中，我们使用shell脚本转换为release-v1-0-1：
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.
02
gitlab-ci内置变量CI_COMMIT_REF_SLUG
可能Gitlab-ci早就关注到这个问题， 在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] 是最优解，完美规避了gitflow branch和Docker image tag的命名冲突。
本文基本没啥技能点， 单纯记录在Devops路上的一个小插曲，前人栽树后人乘凉；
顺便表明一个态度，希望在流畅、自然的开发流程上深耕。
