build(deps): bump cachix/install-nix-action from 20 to 22

[dependabot]

Bumps cachix/install-nix-action from 20 to 22.

Release notes

Sourced from cachix/install-nix-action's releases.

install-nix-action-v22

• Nix 2.16.1
• Fix issues with System Integrity Protection when using macos-12

install-nix-action-v21

• pin Nix to 2.15.1 (recent releases broke too many things)
• fix the action to work on custom containers

Commits

• 6ed004b Merge pull request #184 from cachix/macos-bump
• e278794 Nix: 2.15.1 -> 2.16.1
• 8ab3881 use system certs
• 16b9514 Merge pull request #182 from l0b0/feat/configure-editors
• 2c203fd feat: Configure editors
• 4b933aa Nix: 2.15.1
• 3580693 Merge pull request #179 from joergdw/fix-action-path
• 3eb7a24 Merge pull request #178 from cachix/docs/149
• 840ed7c Document how to pass env vars to modern nix commands
• b2f4229 Fix action to make it work on custom containers;
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[phip1611]

@nicholasbishop It's a bit annoying to always rebase branches when the changes are small... it causes many delays. Do we want to loosen the merge restriction rules?

I'm a big fan of clean git histories and rebases, but I think in this case, it's okay to not have a 100% linear history?!

[nicholasbishop]

Our current settings don't require a linear history, but they do require an up-to-date branch to make sure that CI is testing the same thing that will actually get merged.

Personally I don't much mind the delays our current workflow causes. However, perhaps we could start using Github's new merge queue feature? https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

It's not as flexible as I might personally prefer, but it seems like a good way to avoid having to update branches manually, the merge queue will take care of it. We can set it to do either a rebase or a merge.

[phip1611]

Personally, I'm always in favor of rebases of all branches and a dedicated merge-commit. Would love to see if the merge queue feature can help us to automate that process.

[nicholasbishop]

I don't think the merge queue has an option to both rebase and do a merge commit. For now I've set it to merge mode, so it will always create a merge commit. We can give it a try and adjust (or turn off merge queue) depending on how it works out.

(Philosophical aside: my personal preference is for a linear history, no merge commits. However, I think that slows things down a lot for projects like this that get a good number of external contributions. Many people aren't used to a rebase workflow, and git rebase can be a complicated tool to use and people might accidentally lose work if they are learning it for the first time. So I think allowing non-rebase merges is good for us, even though I like commit linearity.)

[phip1611]

@nicholasbishop

my personal preference is for a linear history, no merge commits

Out of curiosity: Why do you prefer it? IMHO, a merge commit is beneficial for all larger bug fixes and new feature (more than one commit), when individual commits alone do not make sense or break the build.

A merge commit enables to easily revert a whole feature or a complex bugfix. With a linear history, it is not visible at a first glance, where a certain feature or bug fix starts and ends, if it is split across multiple subsequent commits.