Add a new flag to use as target date

[AvdLee]

Our previous implementation contained a bug in which the date of triggering the release would be used as a limit range for the changelog creation. This would cause incorrect changelog updates and issue messages sending out that something was released while it actually was not.

By introducing a new changelogToTag parameter, we're solving this.

[wetransferplatform]

	Messages
📖	View more details on Bitrise
📖	GitBuddyTests: Executed 52 tests (0 failed, 0 retried, 0 skipped) in 1.074 seconds

Code Coverage Report

Name	Coverage
GitBuddy	0.00%	⚠️

Generated by 🚫 Danger Swift against b0a4461

[BasThomas]

I'm going to leave a review as-is; I haven't looked at the Tag.swift and ReleaseProducer.swift in detail, as I'm having trouble understanding the logic.

I'm aware this is the first I've seen of this code base, so perhaps part of it is me. Happy to jump on a call to look at this with together with someone though! :)

[BasThomas]

Suggested change

	@Option(name: .customLong("changelogToTag"), help: "If set, the date of this tag will be used as the limit for the changelog creation. This variable should be passed when `tagName` is set. Default: latest tag.")
	@Option(name: .customLong("changelogToTag"), help: "If set, the date of this tag will be used as the limit for the changelog creation. This variable should be passed when `tagName` is set.")

As I understand this does not have a default, does it?

[AvdLee]

It actually has!

let changelogToTag = try changelogToTag.map { try Tag(name: $0) } ?? Tag.latest()

The variable is required if a specific tagName is set since the latest tag is yet to be created.

There are basically two scenarios:

• Creating a release after a tag was already created
• Creating a release and with that creating a tag using tagName

For the first scenario, it's clear that the changelog should be created using range [previousTag - lastTag]. For the second scenario, however, we're creating a release from a certain commit or branch which we can't use as trailing boundary for the changelog creation. Therefore, it's required to help GitBuddy by informing which boundary tag to use.

Let me know if that clarifies things!

[BasThomas]

Gotcha! I got confused about the default because the specific option variable itself did not have a default. 😄

[AvdLee]

Ah yeah, I see! I guess the default value is not always provided through the command interface. Especially in this case, since it performs actual git operations at the moment of execution :)