jx: Latest and previous tag for changelog generation not correct
Summary
The issue with jx step changelog
has been existing for a long time.
In short, the command doesn’t pick up latestTag
and previousTag
correctly.
I dig into the source code and find the git command that jx
calls is not reliable.
latestTag, err := g.gitCmdWithOutput(dir, "describe", "--abbrev=0", "--tags", "--always")
previousTag, err := g.gitCmdWithOutput(dir, "describe", "--abbrev=0", "--tags", "--always", latestTag+"^")
Take my project as an example. If I issue the command:
git describe --abbrev=0 --tags --debug # find latest tag
describe HEAD No exact match on refs or tags, searching to describe lightweight 2241 6.9.1 lightweight 2239 6.8.1 lightweight 2242 6.8.0 lightweight 2255 6.7.1 lightweight 2308 6.7.0 lightweight 2336 6.6.1 lightweight 2364 6.6.0 lightweight 2371 6.5.1 lightweight 2396 6.5.0 lightweight 2407 6.4.1 traversed 3028 commits more than 10 tags found; listed 10 most recent gave up search at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6.9.1
git describe --abbrev=0 --tags --debug --always 6.9.1^ # find previous tag
describe 6.9.1^ No exact match on refs or tags, searching to describe lightweight 115 6.8.1 lightweight 118 6.8.0 lightweight 131 6.7.1 lightweight 184 6.7.0 lightweight 212 6.6.1 lightweight 240 6.6.0 lightweight 247 6.5.1 lightweight 272 6.5.0 lightweight 283 6.4.1 lightweight 288 6.4.0 traversed 290 commits more than 10 tags found; listed 10 most recent gave up search at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 6.8.1
So I get previousTag
= 6.8.1
, while it’s a very old tag, the latest should be v6.10.194
and previous should be v6.10.193
(After a previous jx upgrade, it adds a “v” as a prefix in the label, and I don’t know when)
I can prove this by checking the tags with another way:
git describe --tag $(git rev-list --tags --max-count=10 --skip=0)
v6.10.194 v6.10.193 6.9.1-2241-gxxxxxxxxxx 6.9.1-2240-gxxxxxxxxxx v6.10.192 6.9.1-2239-gxxxxxxxxxx 6.9.1-2238-gxxxxxxxxxx v6.10.191 v6.10.190 6.9.1-2237-gxxxxxxxxxx
The Consequence
-
Extremely slow CI process
-
The releases chart too long (releases.jenkins.io must have at most 262144 characters)
-
Repeated release note (not only to me, I can see lots of repeated change logs in jx release page as well)
Could someone take a look? It’ really a pain.
Jx version
The output of jx version
is:
NAME VERSION
jx 2.0.56
jenkins x platform 2.0.151
Kubernetes cluster v1.13.1
kubectl v1.14.0
helm client Client: v2.11.0+g2e55dbe
git git version 2.21.0
Operating System Mac OS X 10.14.4 build 18E226
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 21
Commits related to this issue
- fix(git): improve GetCurrentGitTagSHA and GetPreviousGitTagSHA implementation fix for issue #3866 Signed-off-by: Hardy Ferentschik <hardy@ferentschik.de> — committed to hferentschik/jx by hferentschik 5 years ago
- fix(git): improve GetCurrentGitTagSHA and GetPreviousGitTagSHA implementation fix for issue #3866 Signed-off-by: Hardy Ferentschik <hardy@ferentschik.de> — committed to jenkins-x/jx by hferentschik 5 years ago
- fix(git): improve GetCurrentGitTagSHA and GetPreviousGitTagSHA implementation fix for issue #3866 Signed-off-by: Hardy Ferentschik <hardy@ferentschik.de> — committed to daveconde/jx by hferentschik 5 years ago
Awesome! Your thought is more comprehensive and I agree that the merge-base can meet our requirement (and we can start from “master” branch and add support to “release” branch later)
I’ll run some tests on your dev branch and provide feedback 😃