feat: Add --tag-filter-pattern flag.

[evanchaoli]

What does this do / why do we need it?

Our project tags the git repo in many ways. Several CI pipeline will tag with different prefixes. But we only want to include certain tags in CHANGELOG.

How this PR fixes the problem?

This PR adds a flag --tag-filter-pattern. This flag specifies a regular expression and only matched tags will be included in change log.

What should your reviewer look out for in this PR?

Code change is tiny. No much special. The major change is in tag_reader.go.

Check lists

• Test passed
• Coding style (indentation, etc)

Additional Comments (if any)

NA

Which issue(s) does this PR fix?

fixes #43

[coveralls]

Pull Request Test Coverage Report for Build 125

• 17 of 59 (28.81%) changed or added relevant lines in 4 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+5.006%) to 75.153%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
cmd/git-chglog/main.go	10	52	19.23%

Files with Coverage Reduction	New Missed Lines	%
cmd/git-chglog/main.go	2	67.86%

Totals
Change from base Build 111:	5.006%
Covered Lines:	1597
Relevant Lines:	2125

---

💛 - Coveralls

[evanchaoli]

Can anybody please help review and merge this PR? I have added two new tests to test my change, however the coverage still dropped 0.2% because I added a CLI flag, which is 7 lines added, but main.go has no test case.

[evanchaoli]

@tsuyoshiwada Can you please review this?

[evanchaoli]

In order to fix the dropped coverage rate, I had to add main_test.go and refactored main.go a little bit.

[evanchaoli]

@tsuyoshiwada Can you please help review this PR?

[alexanderwe]

I would really like to see this land. I want to git-chglog it one of my projects, but only want to include certain tags into the changelog.

[rivy]

IMO, I think this might be better as a configuration option in config.yml instead of as a command line option.

Having both would work as well, but I think it's a fairly unchanging repository-specific configuration and would be better placed within config.yml.

Here's a quick patch which converts your PR into a config.yml option (see 80b6c3b).

[alexanderwe]

@rivy I agree that it would be neat to also have it as a config.ymloption.
But especially on CI/CD servers where I might want to exclude some tags based on certain conditions, a command line argument is more flexible IMO.
So both would be perfect, but I would not prefer to drop the CLI argument

[evanchaoli]

@rivy Let me explain our use case a little bit. In our project, we have several CI/CD pipelines running for per-push, daily, weekly builds, each tag the repo with different tag prefixes. So that each pipeline needs to use different tag-prefix, but they share same config.yml option.

Actually, I have the other change, adding Jira integration. I thought to raise a PR for that change once this PR is merged, but looks like the owner of this repo is not responsive, I was thinking to clone and maintain my own fork in last week.

[wadackel]

@evanchaoli @rivy @alexanderwe

I'm really sorry for the late response... 🙇

I agree to support only the CLI flag in this change.
I think that it is better to add a function that uses config.yml if necessary.

[wadackel]

I'm terribly sorry late...

Thank you for perfect work 🙏

[wadackel]

Released as 0.9.1.