Move towards changelog generation

[Darhazer]

In the past months I notice much higher activity in the rubocop-rspec. This means that after any merge, a lot of PRs have to be updated to resolve the changelog conflict, just to be updated again on the next merge. Perhaps it's time to move to the same strategy of changelog being generated, with individual changelog files for each PR, like in rubocop and rubocop-rails ?

[pirj]

Using a per-file custom git merge strategy .gitattributes:

CHANGELOG.md      text merge=union

main $ git merge two

* three
* two

1.2

* one

1.1

* foo
* bar

🎉

[pirj]

Well, we kind of already had that:

75fc8d38d (John Backus 2017-01-12 22:10:12 -0800> CHANGELOG.md merge=union

but it missed the text part.
I've sent a PR.

Let's stick to the strategy of:

1. removing the header

# Changelog

## Master (Unreleased)

2. Asking contributors to add their change to the top
3. Observe how it goes

[pirj]

Note to self - adding the changelog entry to the top (e.g. #1438) still caused other PRs to have a merge conflict.

[bquorning]

I tried the CHANGELOG.md text merge=union in a private repo. Merging locally works fine, but GitHub still sees a conflict.

I searched a little bit around and found these interesting posts:

• https://github.com/orgs/community/discussions/9288
• Support of merge=union isaacs/github#487
• merge=union olivierlacan/keep-a-changelog#56

tl;dr: Github UI still doesn’t support merge=union, but it seems that GitLab does.

[pirj]

Some say there's an alternative manual approach to achieve the same:

[merge "aggregate"]
    name = aggregate both new sections
    driver = git merge-file --union -L %P %A %O %B

However, .git/config is not pushed, and adding this to either .gitconfig or .git/config didn't help.
And I can't find merge.aggregate in man git-config 🤔

[bquorning]

If GitHub doesn’t respect .gitattributes, and we cannot push any git config to the repository, then I cannot see how we can fix the issue without splitting the changelog entries into separate files (or into separate parts of the same file, which I'm not sure would help at all).

[pirj]

GitHub actions could have helped, but "Workflows will not run on pull_request activity if the pull request has a merge conflict".

There's an action that marks a PR with a label when it needs a rebase (source). Wondering if it's possible to adjust it to rebase it using a script.

[bquorning]

I imagine having your branch rebased by a script would feel disruptive to our contributors.

[pirj]

To round it up, we're dealing with two issues here:

1. Maintainers can't merge more than one PR in a row without getting a merge conflict on the subsequent PRs
2. Contributors or maintainers have to rebase and force-push before the PR can be merged

On the other hand, the file-based changelog entry approach:

1. (subjective) Offers less discoverability into what has been added in the integration branch
2. (?) adds a one command step to the release process
3. • offers solutions for the two main issues we have
4. (subjective) adds some cognitive overhead to entry file creation

Given there are no sane options to deal with a single changelog file, I give up and agree with the multi-file appoach.

[koic]

I'm late riding on this one.
If you like, I'll bring RuboCop and RuboCop Rails changelog logic to RuboCop RSpec.

• Add rake tasks for alternative way to specify Changelog entries rubocop-rails#496 and other PRs

After introducing the current RuboCop changelog logic, the number of collisions has definitely decreased.
OTOH, It differs from @pirj approach #1425 which has already been opened. If you don't mind, shall I open a PR to bring the RuboCop changelog logic? (It may be a little later because I'm busy with other work on this week)

Or, if you try #1425 first, I'll pend my action.

[pirj]

This is very kind of you, @koic . I've closed #1425 in favour of a commonly used approach.

[koic]

I got it. Please be patient while I open a PR.

[ydah]

Once attempted, but currently unnecessary, so will proceed again when demand increases:

• Add rake tasks for alternative way to specify Changelog entries #1542