Closed janarvaezkng closed 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?
🤔 not really, since it was working before within cloudbuild... I'll keep investigating and see if I can find the issue
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)
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)
Ah thanks for this, it gives me a better insight. I'll try a few things and let you know
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 🙂
No worries at all! Glad you got it working
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
commit-and-tag-version
version(s): v12.4.1Possible Solution
Additional context Add any other context about the problem here. Or a screenshot if applicable