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

Most upvoted comments

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 😃