打包生成版本号疑问

Choerodon User Guide
#1

  • Choerodon平台版本：0.17.0

  • 运行环境：自主搭建

  • 问题描述：

image
image1638×346 98.3 KB

我怎么觉得都不是哇？总不是随机生成的吧

#2

是打包时间 只不过 gitlab-runner 容器时区不对。。。。

你们安装文档 可以 安装gitlab的时候 把 时区调整下，不然打包时间对不上。。。

#3

你好，打包出来的版本为本地执行 git commit 命令的时间，时间和时区都是取的 git版本库 中记录的信息。

详细实现请查看 .auto_devops.sh详解

https://choerodon.io/zh/docs/development-guide/basic/gitlab-ci/

#4

这个取的 gitlab 容器时间？ 这时间明显是有时区问题的 我进gitlab date 看时间是对的

#5

建议不要 不要用时间 昨晚版本号 按道理应该去 commitid 哇

#6

image
image964×200 68.4 KB

你这几个 变量取的时间 是哪个容器的时间？

#7

看到了
是git log里的

#8

那还是 gitlab 容器时间问题 还是 用 的utc 时间

#9

你好，获取的时间全部都是从 Git版本库 中获取的，取出来的时间是你在本地执行 git commit 命令的时间，这个时间只和你在执行该命令的环境有关系，在取这个时间的时候与其他环境的时间和时区没有任何关系。

#10

怎么会这么取时间 算了 我自己改下这个 变量算了 完全没版本号的概念

#11

如果你在Gitlab界面上进行代码修改提交或分支合并等会影响版本库指针的操作那就是Gitlab容器中的时间和时区了。

#12

按你的意思 每次merge 时间 都是有问题的， 用户 电脑时间有问题 也不准。。。
这个版本号太不靠谱了

#13

你好，这个 版本号 获取是永远不会变的，所以我们才采用这个方案，如果你有更好的方案请告知我们，我们一定进行改进，谢谢。

PS: 由于 helm 版本号必须遵循 语义化版本 规则，请设计版本号获取时考虑到这一点

#14

我个人 建议是 改成 项目名称-打包时间+commitid（短）- branch

我自己 gitlab-ci 自己重新定义下 ${CI_COMMIT_TAG} 这个变量 覆盖下 行的吧？

#15

是可以覆盖的哈

#16

但是这个方案会出现以下情况：

  1. 同一份代码跑多次CI会出现多个版本，就只能看commitid判断了
  2. 短时间内提交了多次代码到gitlab触发CI，但是在跑CI时可能会出现资源不足等其他因素导致后提交的代码跑CI先完成，最初提交的代码跑CI后完成，这样也就只能看commitid判断先后了，这个在部署应用的时候就是一件比较闹心的事了
#17

你这 理解有问题吧：

  1. 同一份代码 多次ci 多个版本 ，只能看打包时间判断了，不过无所谓 同一份代码 commitid肯定一样 没关系的 代码是对就行
  2. 短时间 提交多次代码 触发 ci ，不管他什么版本 只要 对 commitid 就行了 commitid 最新可以了

你这种去时间的方法 压根没法 跟代码版本 对应起来， 没 commitid 关联起来 这才是头痛的事，比如我要回滚某次commitid 我这么找对应的版本号。。。，就算可以根据你这时间找出来 但肯定没 commitid 方便的

#18

所以我就很好奇做版本号 竟然不用commitid 做关联 确实有点不解。。。。

#19

你们gitlab 直接 设 TZ 环境变量 改时区是不行的，得把/etc/localtime改掉，不然 提merge 版本时间是不对的，推荐直接把宿主机/etc/localtime 挂进去

gitlab 改时区
        volumeMounts:
        - mountPath: /certs
          name: gitlab-data
          subPath: certs
        - mountPath: /var/log/gitlab
          name: gitlab-data
          subPath: logs
        - mountPath: /var/opt/gitlab
          name: gitlab-data
          subPath: data
        - mountPath: /etc/gitlab
          name: gitlab-data
          subPath: config
        - mountPath: /opt/choerodon/paas/etc/gitlab.rb
          name: gitlab-config
          subPath: gitlab.rb
        - name: host-time
          mountPath: /etc/localtime
          readOnly: true
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: gitlab-data
        persistentVolumeClaim:
          claimName: gitlab-pvc
      - configMap:
          defaultMode: 420
          name: gitlab-cm
        name: gitlab-config
      - name: host-time
        hostPath:
          path: /etc/localtime
#20

你好，请站在一个运维部署人员的角度考虑一下，他们是不关心代码和提交记录情况的，他们在部署的时候首要是依据版本号大小进行衡量该部署哪一个，如果他们在部署的时候还得去看看代码库里面的commitid才能确认该部署哪一个，实质上这个版本号也就失去了他真正的意义。