ap0llo / changelog Goto Github PK

Allow writing multiple change log entries in a single commit (e.g. separated by ---).

While this is not compliant with the conventional commits specification, this might be useful in situations where multiple features are implemented at once (which cannot always be avoided)

Hi!

Thank you for this handy tool. I am currently migrating our build system to dotnet5 and it would help a lot.

In your repo I can see that you did quite some changes since the last release to NuGet, especially dotnet5 targets.

Would you mind to trigger a new release there?

Thanks!

great work! congrats

My use case is to generate the changelog using Nuke.build building process. To use the generator via c# code directly. Currently, I have to call it as a separate program.

It would be nice to have an entry point to pass all the arguments as an options class or option by option.

regards!

Given I am creating a release for a project within a monorepo
When I generate a changelog
Then I expect to be able to optionally specify a scope
And I expect only commits to that scope be included in my generated change log
And for that changelog to be written to a particular output path

This is primarily to have this tool be more useful in a monorepo where there are multiple libraries being independently versioned with nbgv (separate version.json files in different subfolders).

I'll elaborate on this a bit more (with respect to expected project structure that is driving this request). It may also be something I plan on contributing myself (life-willing).

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>whitesource/merge-confidence:beta)

Intro

In some scenarios, just providing a description of a commit is not sufficient to describe a change because the change does not stand on its own.
These Relationships between change log entries could be modeled using special directives in commit messages that define these relationships.
These could then be taken into account when generating the change log and activate additional behavior.

Format

Entry relationships can be modeled as regular footers which keeps compatibility with the Conventional Commits specification.
A entry relationship consists of a type and a referenced entry:

• The relationship type is modeled as a footer's name
• The referenced entry is specified in the footer's value using the entry's git commit sha

For example, a bug fix that reverts a previous commit, could model this relationship using a Reverts footer:

fix: fix a bug

Description of the bug fix

Reverts: d81a8dbdb6bbb815f13633cf2be066005846d320

Relationship types

Message-For

Overrides a entry's commit message with a different message

Reverts

Indicates that a commit x reverts a previous commit y:

• If both x and y belong two the same version, neither entry is included in the change log
• If x and y belong to different versions, the change log will contain a link between the two entries

Fixes

Indicates that a commit x fixes a bug introduced by commit y.

• If both x and y belong two the same version, x is omitted from the change log (because the bug was introduced in the same version and hence the bug is not a change compared to the previous version)
• If x and y belong to different versions, the change log will contain a link between the two entries

Replaces

Indicates that a commit x replaces a different commit y.

All occurrences of commit y in the change log are replaced with the entry for x

Open questions ❓

• Is there special handling for transitive dependencies required? (e.g. using the commit 1 includes a "Message-For" footer for commit 2 but commit 3 includes a "Message-For" footer for commit 1)
• Can an entry define multiple relationships?
• Revert: Can the revert commit itself be reverted?
• Do "relationship footers" show up in the output or are they removed?

In the latest version of the Conventional Commits specification specification, mutli-line footers are explicitly allowed:

10. A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.

This is currently not supported by the commit message parser.

Support for multi-line footers should be added on order to be conformant to the specification.

Add an option to configure which entries are included in the change log.

Currently, by default, all parsable messages within a version range are included if the message type is feat or fix.
Additional types of changes can be included using the "Entry types" setting.
This setting however behaves differently from the similar settings scopes and footers:

• The scopes and footers settings do not change if a entry is included in the change log but only influence how it is displayed.
• The types setting changes both if entries of a certain type are included and how they are displayed.

A separate filter setting could remove that discrepancy: The types should only change how entries are displayed, the filter setting controls which changes are included.

The filter setting could also be implemented in a way that allows filtering based on other properties of a entry, not just the entry type.

Hello,

I just figured out that this tool runs into the error shown below when it's not running on a full clone of the repository:

INFORMATION - Loading commits
Unhandled exception. LibGit2Sharp.NotFoundException: object not found - no match for id (4f9b53155d97e9f38e720ad45b60cc72a06f5314)
  at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 154
  at LibGit2Sharp.Core.Ensure.ZeroResult(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 172
  at LibGit2Sharp.Core.Proxy.git_revwalk_next(RevWalkerHandle walker) in /_/LibGit2Sharp/Core/Proxy.cs:line 2774
  at LibGit2Sharp.CommitLog.CommitEnumerator.MoveNext() in /_/LibGit2Sharp/CommitLog.cs:line 140
  at System.Linq.Enumerable.SelectEnumerableIterator`2.ToList()
  at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
  at Grynwald.ChangeLog.Git.GitRepository.GetCommits(Nullable`1 fromCommit, GitId toCommit) in /_/src/ChangeLog/Git/GitRepository.cs:line 52
  at Grynwald.ChangeLog.Tasks.LoadCommitsTask.Run(ApplicationChangeLog changeLog) in /_/src/ChangeLog/Tasks/LoadCommitsTask.cs:line 49
  at Grynwald.ChangeLog.Tasks.SynchronousChangeLogTask.RunAsync(ApplicationChangeLog changeLog) in /_/src/ChangeLog/Tasks/SynchronousChangeLogTask.cs:line 11
  at Grynwald.ChangeLog.Pipeline.ChangeLogPipeline.RunAsync() in /_/src/ChangeLog/Pipeline/ChangeLogPipeline.cs:line 40
  at Grynwald.ChangeLog.Program.RunAsync(GenerateCommandLineParameters commandlineParameters) in /_/src/ChangeLog/Program.cs:line 176
  at Grynwald.ChangeLog.Program.Main(String[] args) in /_/src/ChangeLog/Program.cs:line 46
  at Grynwald.ChangeLog.Program.<Main>(String[] args)

Since most CI Systems like GitHub Actions or GitLab Pipelines will not create a full clone but shallow clone with a depth around 10 by default, running the tool will cause the error above after a view commits.

Because this is very unexpected I think a hint to this fact is needed in the documentation, so users can setup there CI jobs with a full clone before the error occurs.

Now that .NET6 is officially released, it would be great to support it.