Skip to content

fix(#271): add annotated_tag option to bump #272

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.

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

Closed

Conversation

diefans
Copy link
Contributor

@diefans diefans commented Sep 22, 2020

Enable creation of annotated tags when bumping.

Description

Create annotated tags, when bumping.

Checklist

  • Add test cases to all the changes you introduce
  • Run ./script/format and ./script/test locally to ensure this change passes linter check and test
  • Test the changes on the local machine manually
  • Update the documentation for the changes

Expected behavior

With annotated_tag enabled commitizen will create annotated tag instead of lightweight ones.

Steps to Test This Pull Request

Use cz bump --annotated_tag or annotated_tag = 1 in config file

Additional context

maybe related to #261 ???

@codecov
Copy link

codecov bot commented Sep 22, 2020

Codecov Report

Merging #272 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #272      +/-   ##
==========================================
+ Coverage   96.61%   96.62%   +0.01%     
==========================================
  Files          33       33              
  Lines         915      919       +4     
==========================================
+ Hits          884      888       +4     
  Misses         31       31              
Flag Coverage Δ
#unittests 96.62% <100.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
commitizen/cli.py 97.36% <ø> (ø)
commitizen/__version__.py 100.00% <100.00%> (ø)
commitizen/commands/bump.py 90.58% <100.00%> (ø)
commitizen/commands/check.py 100.00% <100.00%> (ø)
commitizen/git.py 95.55% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d8e9bad...d2b0ebe. Read the comment docs.

@woile
Copy link
Member

woile commented Sep 23, 2020

Even if this were unrelated to the original issue (not triggering a workflow). I think it would be useful for traceability. An annotated tag adds:

  • date
  • creator
  • message -> it could even contain the changes from the release which would appear in the changelog

I'll test how it could works, for v3 could be the default.

What do you think @Lee-W ?

    Enable creation of annotated tags when bumping.
@diefans diefans force-pushed the 271/annotated_tag_option branch from ad554a4 to d2b0ebe Compare September 23, 2020 14:22
@@ -216,6 +214,15 @@ Some examples
bump_message = "release $current_version → $new_version [skip-ci]"
```

### `annotated_tag`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for consistency, I'll suggest using --annotated_tag

### `annotated_tag`

Whether to create annotated tags or lightweight ones.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If my understand is correct, we can use cz bump -at and set it in config to achive it. If so, I'd suggest adding both usages here.

@@ -131,6 +131,11 @@
),
"action": "store_true",
},
{
"name": ["--annotated-tag", "-at"],
"help": "create annotated tag instead of lightweight one",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can change the help message to create an annotated tag (by default, commitizen creates lightweight tag)

c = git.tag(new_tag_version)
c = git.tag(
new_tag_version,
annotated=self.bump_settings.get("annotated_tag", False)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to enhance readbility, I would suggest make self.bump_settings.get("annotated_tag", False) or or bool(self.config.settings.get("annotated_tag", False)) a variable. I read this line for a few times to understand

@Lee-W
Copy link
Member

Lee-W commented Sep 24, 2020

Even if this were unrelated to the original issue (not triggering a workflow). I think it would be useful for traceability. An annotated tag adds:

* date

* creator

* message -> it could even contain the changes from the release which would appear in the changelog

I'll test how it could works, for v3 could be the default.

What do you think @Lee-W ?

Although I love this feature, I'm a bit against making it a default option. I'm not sure how common annotated tag is used in practice.

@woile
Copy link
Member

woile commented Sep 24, 2020

Doing man git-tag gives this:

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.

Here's an answer from SO

I have the same concerns as you, not sure how used is in practice, spite of what the documentation says.
But let's see, maybe once we start using it, it does make more sense.

@Lee-W
Copy link
Member

Lee-W commented Sep 26, 2020

Got it. It makes more sense after reading it. I'm now neutral to make it as a default.

@woile
Copy link
Member

woile commented Nov 11, 2020

Please remove the changes on CHANGELOG.md and rebase. Looks good.

cliles added a commit to cliles/commitizen that referenced this pull request Jan 15, 2021
@cliles cliles mentioned this pull request Jan 15, 2021
4 tasks
@woile
Copy link
Member

woile commented Mar 5, 2021

This was already added

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants