There's a lot in this PR.
- Added a Section class to more easily make the other changes and
hopefully add flexibility for the future
- Added an option called `configure_sections` that allows you create
your own custom sections. It blows away all other sections and uses
only the ones you give it.
- Added an option called `add_sections` that allows you to add_sections
to the default section set
- Added an option called `include_merged` that can be used when
configure_sections is defined. Configure sections blows away any and
all default sections so to get this one back, you have to set this
option.
- Added tests for this stuff
@HAIL9000 was a co-author. Because of a little git snafu, I accidentally
squashed all of our work into one so it looks like it was just me.
---
Refactor details:
Before this change, the code in generator.rb and generator_generation.rb was conflated and
method call flow went back and forth between the two files seemingly
randomly. They also both defined the exact same class, which is
un-ruby-ish. I tried to separate methods used for the whole changelog
generation from methods used for specific parts of the changelog and
move them into specific classes.
I reasoned that a changelog is a series of "entries" of all tagged
releases plus an extra entry for the unreleased entry. Each entry is
comprised of a header and a series of "sections" for that entry. Each
section is comprized of a list of issues and/or pull requests for that
entry. So the log contains entries, entries contain sections, and
sections contain issues & prs. I have structured the classes around this idea.
- lib/github_changelog_generator/generator/generator.rb is for code
related to generating the entire changelog.
- lib/github_changelog_generator/generator/entry.rb is for code related
to generating entries.
- lib/github_changelog_generator/generator/section.rb is for code
relating to geneating entry sections.
Issues and PRs are already special objects, so it doesn't make sense to
break those out into their own class.
Because we need might need excluded tags to build compare links, the
section map generator needs to have access to those tags. But, we don't
want excluded tags to have section headers. So instead, we'll create
another copy of the list that doesn't have tags excluded.
Signed-off-by: Tom Duffield <tom@chef.io>
This change neccesitated changing the behavior or the
`filter_since_tag`. Since we want our compare links to include the since
tag, we need to keep that tag in the filtered list. Instead, we detect
that the tag is the since tag and filter it out. This will prevent the
since_tag header from being duplicated when pulling from a base.
The same goes for the first tag listed in between_tags. We don't want an
empty section header for this.
Signed-off-by: Tom Duffield <tom@chef.io>
