absolute-version / commit-and-tag-version

Fork of the excellent standard-version. Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org :trophy:
ISC License
425 stars 40 forks source link

Only bumping up patch versions in pipeline #174

Closed janarvaezkng closed 3 months ago

janarvaezkng commented 3 months ago

Describe the bug After migrating from standard-version, when running in a CloudBuild pipeline, my package version only gets bumped as a patch version every time. Doing a dry-run in my local works as expected, but for some reason the pipeline doesn't recognise the commits.

I used to have this issue before with standard-version, and fixed it by doing a git pull --tags beforehand, although now simply swapping libraries seems to start failing again, even with the pull.

Current behavior bumps up only patch version, no matter if the latest commits include feat: ...

Expected behavior bumps up the package with a minor version

Environment

Possible Solution

Additional context Add any other context about the problem here. Or a screenshot if applicable

TimothyJones commented 3 months ago

There’s nothing different between the two tools that should cause this- are you sure it’s not a cloudbuild setting causing the pull to not work correctly?

janarvaezkng commented 3 months ago

🤔 not really, since it was working before within cloudbuild... I'll keep investigating and see if I can find the issue

TimothyJones commented 3 months ago

Can you confirm which is the last version that currently works? A current test will eliminate whether or not it's a cloudbuild setting.

(the versions of commit-and-tag-version and standard-version are equivalent)

TimothyJones commented 3 months ago

Sidenote: I checked the docs for cloudbuild - it does a shallow clone with --depth 1. Unless I'm missing something, I don't think you can use git pull --tags to get the rest of the commits - if it was working before, I'd guess (something like) cloudbuild didn't previously do a shallow clone, something has changed between git versions, or some other process was unshallowing the checkout for you.

You can verify this by cloning a repository with git clone --depth 1 <some repository url>, changing to that directory, and then doing git pull --tags - you'll see that yes, all the tags come down, but git log will show that the past commits aren't there.

I think you'll instead have to use git fetch --unshallow - which is also what's recommended by the cloudbuild docs.

(if you try this in a test repository, you can then see that the past commits are there along with the tags)

janarvaezkng commented 3 months ago

Ah thanks for this, it gives me a better insight. I'll try a few things and let you know

janarvaezkng commented 3 months ago

Right, after a few tests, git fetch --unshallow --tags fixed the thing.

git fetch --tags as you mentioned, would only bring the last commit so the version will be based on that single commit message git fetch --unshallow would bring all commits, but create a version taking ALL of them into account, ignoring previous versions. git fetch --unshallow --tags brings all the necessary info to generate the correct version and tag

Not sure where, when, how this broke since the pipeline had been working for about 2 years and the only change I had was migrate to this package in the last month or so (although I might have missed something, or maybe it was something in the cloud build ecosystem).

Thanks a lot for the help, and sorry for taking your time 🙂

TimothyJones commented 3 months ago

No worries at all! Glad you got it working