CI: install changelog-d from bindist

[fgaz]

This will avoid build problems when the GHC in the CI environment is updated sooner than expected.
Previous breakage: #9177 (comment)

---

Template B: This PR does not modify behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[ulysses4ever]

Thanks!

And this should be expedited (exempt from the two-days delay).

[Mikolaj]

Thank you.

[ulysses4ever]

@mergify backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #10053 CI: install changelog-d from bindist (backport #10048) has been created for branch 3.12 but encountered conflicts

[ulysses4ever]

@Mergifyio refresh

[mergify]

refresh

✅ Pull request refreshed

[fgaz]

It's one commit so we can squash, no?

[ulysses4ever]

pr:squash label doesn't do anything magical, it's just a reminder to squash manually if the branch is protected and the bot can't do that by itself. But in this case, no squashing is needed exactly because there's just one commit (and the branch is not protected either). So, the label isn't needed either.

Current status: the branch was rebased on master by the bot, and the CI has to re-run and complete before the bot will merge it to master. If no one removes the necessary labels (merge-me, merge delay passed) that is.

[fgaz]

Yeah sorry I made a bit of a mess with labels. I think it makes sense to also squash-merge prs with a single commit, since there isn't anything to group up, but feel free to revert the label change

[ulysses4ever]

I don't know if 1-commit PRs squashed look the same as merged. They probably are, and in that case, it doesn't matter which label to use.

[geekosaur]

The squash per se does nothing since there's nothing to squash. The only significant difference is whether it does a merge or a rebase to get it into master, and IIRC both labels use the same strategy.

ETA: looks like our squash+merge me uses merge instead of rebase as merge me does. But the comment on it says that the squash part makes them do the same thing.

[fgaz]

I don't know if 1-commit PRs squashed look the same as merged. They probably are, and in that case, it doesn't matter which label to use.

They look different: squash+merge will result in one commit with (#10048) appended to the first line of the commit message, while merge will result in two commits: the one being merged and the merge commit Merge #10048 into master

[ulysses4ever]

squash+merge will result in one commit with (#10048) appended to the first line of the commit message, while merge will result in two commits: the one being merged and the merge commit Merge #10048 into master

Oh, I prefer the former very much. I wish I understood why it works like that. Also, can we set it up so that it never creates these ugly merge commit? (Or am I the only one who doesn't like them?..)

looks like our squash+merge me uses merge instead of rebase as merge me does

hmm, this looks like it should behave the opposite to what fgaz describes in the quote above?.. I'm so confused!

[geekosaur]

I noticed that as well.

What I see in the git log is that merge me results in merge commits and squash+merge me doesn't (as @fgaz says), despite what mergify.yml says. I presume this means that mergify.yml is referring to Mergify's strategy, not the resulting git strategy. This may mean we want to switch the strategy used when merge me is specified.

[ulysses4ever]

Yes!