Lima can't parse version if built from tag with dirty checkout

[arixmkii]

Description

Scenario:

1. checkout tag
2. apply patch using patch command
3. build
4. run integration tests

Error:

time="2025-04-28T17:17:27Z" level=fatal msg="failed to validate YAML file \"D:\\\\a\\\\qcw\\\\qcw\\\\lima-release\\\\templates\\\\experimental\\\\default-windows.yaml\": can't parse builtin Lima version \"v1.1.0.m\": strconv.ParseInt: parsing \"0.m\": invalid syntax"

I added 1.1.0 tag artificially here to have no issues in my development build (no tags fetched) with lima version being too low.

The issue will go away if I tag the previous commit to my build, because ".m" would be in the part cut by splitting on '-' symbol.

I believe that building from a tagged commit with local changes should still result in a working binary.

[afbjorklund]

I added 1.1.0 tag artificially here to have no issues in my development build (no tags fetched)

@arixmkii : why were the tags missing? There seem to be others with the same issue, running into the --always

can't parse builtin Lima version "edec9bc1": edec9bc1 is not in dotted-tri format

I thought the git default was to fetch all tags, that are on the branch that is currently being fetched (e.g. master)?

Maybe it should just fail instead: fatal: No names found, cannot describe anything.

[jandubois]

I thought the git default was to fetch all tags, that are on the branch that is currently being fetched

It only fetches "annotated" tags by default. Our tags are "lightweight tags" only and must be fetched explicitly.

[afbjorklund]

I get all tags (that are on the branch) with git fetch and friends, but I do have to use --tags with git describe (to respect lightweight tags)

But I think you can configure your git to do --no-tags by default, or if you do a shallow clone (depth 1) you might also miss it...

[arixmkii]

or if you do a shallow clone (depth 1)

My scenario was a shallow clone with patches on top. Tag was added to the only commit fetched.