Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Initial tag hard coded to 0.1.0, even when it doesn't match tag_pattern #1066

Closed
1 task done
muja opened this issue Feb 28, 2025 · 7 comments · Fixed by #1070
Closed
1 task done

Initial tag hard coded to 0.1.0, even when it doesn't match tag_pattern #1066

muja opened this issue Feb 28, 2025 · 7 comments · Fixed by #1070
Assignees
@orhun
Labels
bug Something isn't working

Comments

@muja
Copy link

muja commented Feb 28, 2025

Is there an existing issue for this?

  • I have searched the existing issues

Description of the bug

When running git cliff --bumped-version with a tag pattern configured and no matching tags, it will just happily create the hard-coded 0.1.0 tag without validating it against the regex.

Steps To Reproduce

cd $(mktemp -d)
git init .
git commit --allow-empty -m 'chore: initial commit'
git cliff --bumped-version --tag-pattern='foo-[0-9]+\.[0-9]+\.[0-9]+' ## success, prints "0.1.0"

Expected behavior

git cliff creates a tag that passes the regex. Since that is not really trivial and probably not very practical, it should at least refuse to print anything and exit with an error code instead.

Screenshots / Logs

No response

Software information

  • Operating system: n/a
  • Rust version: n/a
  • Project version: 2.8.0

Additional context

I am aware of the initial_tag option. However, it is actually infeasible for us to set this in the cliff.toml as we have one for the whole team. It would be great if this option was available as an ENV or a CLI param.
@muja muja added the bug Something isn't working label Feb 28, 2025
@orhun orhun mentioned this issue Mar 2, 2025
Merged
12 tasks
@orhun
Copy link
Owner

orhun commented Mar 2, 2025

Hey, thanks for reporting 👋🏼

This should be fixed in #1070

I am aware of the initial_tag option. However, it is actually infeasible for us to set this in the cliff.toml as we have one for the whole team. It would be great if this option was available as an ENV or a CLI param.

This is not a very commonly used configuration option, you'd probably only need it once while creating the initial version. But I can implement it if you need it. Just let me know and shoot me another issue :)

@muja
Copy link
Author

muja commented Mar 2, 2025

Well when onboarding other teams to the tool / process (which mandates a tag-prefix for monorepos) this is a common scenario and it's an obstacle to have to tell them "you have to create an initial tag per subcomponent first"

@orhun
Copy link
Owner

orhun commented Mar 5, 2025

Yeah, I see the inconvenience... I just tested this again and realized --bumped-version and --tag could be used together. Also, it yields the value of --tag when there isn't any tag exist yet. Is that an useful behavior for your case?

@muja
Copy link
Author

muja commented Mar 19, 2025 •
edited
Loading

Not really since it always takes the value from the tag argument. However I found another way. I've converted the cliff.toml to yaml and added the bump.initial_tag field to the YAML config using yq (which supports reading but not outputting toml).

@orhun orhun mentioned this issue Mar 19, 2025
Open
1 task
@orhun
Copy link
Owner

orhun commented Mar 19, 2025

Cool! I created #1100 for tracking the --initial-tag feature. Closing this one since the main issue is resolved and the fix will be available as a part of the next release.

@orhun orhun closed this as completed Mar 19, 2025
@muja
Copy link
Author

muja commented Mar 19, 2025

@orhun cool, thanks. BTW I also found out that bump_type = "patch" (as the docs suggest) does not work, it has to be bump_type = "Patch" (I'm too tired to create a new issue, sorry)

@orhun orhun mentioned this issue Mar 19, 2025
Merged
12 tasks
@orhun
Copy link
Owner

orhun commented Mar 19, 2025

Ah damn, that's a good catch! Should be fixed in #1101

It might be a breaking change, but that's how this is intended to be used anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@orhun orhun

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(bump): check the next version against tag_pattern regex orhun/git-cliff
2 participants
@muja @orhun