Bump org.junit.jupiter:junit-jupiter from 6.1.0 to 6.1.1

[dependabot]

Bumps org.junit.jupiter:junit-jupiter from 6.1.0 to 6.1.1.

Release notes

Sourced from org.junit.jupiter:junit-jupiter's releases.

JUnit 6.1.1 = Platform 6.1.1 + Jupiter 6.1.1 + Vintage 6.1.1

See Release Notes.

Full Changelog: junit-team/junit-framework@r6.1.0...r6.1.1

Commits

• 0d85889 Release 6.1.1
• 0363eee Finalize 6.1.1 release notes
• a6d540a Move entry to 6.1.1 release notes
• 69339d5 Only pass timeout when publishing to avoid failure in nmcp plugin
• dec2eb9 Allow excluding engines from memory cleanup mode (#5786)
• a5f4270 Publish sha256/sha512 checksums again but filter out signature ones (#5796)
• 8213012 Update plugin nmcp-settings to v1.6.0 (#5787)
• d1bf847 Generate Javadoc for aggregator modules
• d721de5 Pass --no-fonts to javadoc convention
• d289ec6 Restore original SetSystemProperty values in a ParameterizedTest (#5720)
• 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 show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @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)

[Jikoo]

There doesn't seem to be any documentation on the error message or definition of what "unstable status" is in the manual. Looking into automerge it does appear that the automerge attempt should run first either way, because this is probably a race condition due to AppVeyor starting and changing the status of checks. Since automerge requirements are already met (due to the only required check being the job approve and merge depends on), the CLI should instead attempt to perform a regular merge, which is where the status becomes a problem.