build(deps): bump github.com/onsi/ginkgo/v2 from 2.1.6 to 2.3.1

[dependabot[bot]]

Bumps github.com/onsi/ginkgo/v2 from 2.1.6 to 2.3.1.

Release notes

Sourced from github.com/onsi/ginkgo/v2's releases.

v2.3.1

2.3.1

Fixes

Several users were invoking ginkgo by installing the latest version of the cli via go install github.com/onsi/ginkgo/v2/ginkgo@latest. When 2.3.0 was released this resulted in an influx of issues as CI systems failed due to a change in the internal contract between the Ginkgo CLI and the Ginkgo library. Ginkgo only supports running the same version of the library as the cli (which is why both are packaged in the same repository).

With this patch release, the ginkgo CLI can now identify a version mismatch and emit a helpful error message.

• Ginkgo cli can identify version mismatches and emit a helpful error message [bc4ae2f]
• further emphasize that a version match is required when running Ginkgo on CI and/or locally [2691dd8]

Maintenance

• bump gomega to v1.22.0 [822a937]

v2.3.0

2.3.0

Interruptible Nodes and Timeouts

Ginkgo now supports per-node and per-spec timeouts on interruptible nodes. Check out the documentation for all the details but the gist is you can now write specs like this:

It("is interruptible", func(ctx SpecContext) { // or context.Context instead of SpecContext, both are valid.
    // do things until `ctx.Done()` is closed, for example:
    req, err := http.NewRequestWithContext(ctx, "POST", "/build-widgets", nil)
    Expect(err).NotTo(HaveOccured())
    _, err := http.DefaultClient.Do(req)
    Expect(err).NotTo(HaveOccured())
Eventually(client.WidgetCount).WithContext(ctx).Should(Equal(17))

}, NodeTimeout(time.Second20), GracePeriod(5time.Second))

and have Ginkgo ensure that the node completes before the timeout elapses. If it does elapse, or if an external interrupt is received (e.g. ^C) then Ginkgo will cancel the context and wait for the Grace Period for the node to exit before proceeding with any cleanup nodes associated with the spec. The ctx provided by Ginkgo can also be passed down to Gomega's Eventually to have all assertions within the node governed by a single deadline.

Features

• Ginkgo now records any additional failures that occur during the cleanup of a failed spec. In prior versions this information was quietly discarded, but the introduction of a more rigorous approach to timeouts and interruptions allows Ginkgo to better track subsequent failures.
• SpecContext also provides a mechanism for third-party libraries to provide additional information when a Progress Report is generated. Gomega uses this to provide the current state of an Eventually().WithContext() assertion when a Progress Report is requested.
• DescribeTable now exits with an error if it is not passed any Entries [a4c9865]

Fixes

• fixes crashes on newer Ruby 3 installations by upgrading github-pages gem dependency [92c88d5]
• Make the outline command able to use the DSL import [1be2427]

Maintenance

• chore(docs): delete no meaning d [57c373c]
• chore(docs): Fix hyperlinks [30526d5]
• chore(docs): fix code blocks without language settings [cf611c4]
• fix intra-doc link [b541bcb]

... (truncated)

Changelog

Sourced from github.com/onsi/ginkgo/v2's changelog.

2.3.1

Fixes

Several users were invoking ginkgo by installing the latest version of the cli via go install github.com/onsi/ginkgo/v2/ginkgo@latest. When 2.3.0 was released this resulted in an influx of issues as CI systems failed due to a change in the internal contract between the Ginkgo CLI and the Ginkgo library. Ginkgo only supports running the same version of the library as the cli (which is why both are packaged in the same repository).

With this patch release, the ginkgo CLI can now identify a version mismatch and emit a helpful error message.

• Ginkgo cli can identify version mismatches and emit a helpful error message [bc4ae2f]
• further emphasize that a version match is required when running Ginkgo on CI and/or locally [2691dd8]

Maintenance

• bump gomega to v1.22.0 [822a937]

2.3.0

Interruptible Nodes and Timeouts

Ginkgo now supports per-node and per-spec timeouts on interruptible nodes. Check out the documentation for all the details but the gist is you can now write specs like this:

It("is interruptible", func(ctx SpecContext) { // or context.Context instead of SpecContext, both are valid.
    // do things until `ctx.Done()` is closed, for example:
    req, err := http.NewRequestWithContext(ctx, "POST", "/build-widgets", nil)
    Expect(err).NotTo(HaveOccured())
    _, err := http.DefaultClient.Do(req)
    Expect(err).NotTo(HaveOccured())
Eventually(client.WidgetCount).WithContext(ctx).Should(Equal(17))

}, NodeTimeout(time.Second20), GracePeriod(5time.Second))

and have Ginkgo ensure that the node completes before the timeout elapses. If it does elapse, or if an external interrupt is received (e.g. ^C) then Ginkgo will cancel the context and wait for the Grace Period for the node to exit before proceeding with any cleanup nodes associated with the spec. The ctx provided by Ginkgo can also be passed down to Gomega's Eventually to have all assertions within the node governed by a single deadline.

Features

• Ginkgo now records any additional failures that occur during the cleanup of a failed spec. In prior versions this information was quietly discarded, but the introduction of a more rigorous approach to timeouts and interruptions allows Ginkgo to better track subsequent failures.
• SpecContext also provides a mechanism for third-party libraries to provide additional information when a Progress Report is generated. Gomega uses this to provide the current state of an Eventually().WithContext() assertion when a Progress Report is requested.
• DescribeTable now exits with an error if it is not passed any Entries [a4c9865]

Fixes

• fixes crashes on newer Ruby 3 installations by upgrading github-pages gem dependency [92c88d5]
• Make the outline command able to use the DSL import [1be2427]

Maintenance

• chore(docs): delete no meaning d [57c373c]
• chore(docs): Fix hyperlinks [30526d5]
• chore(docs): fix code blocks without language settings [cf611c4]
• fix intra-doc link [b541bcb]

2.2.0

... (truncated)

Commits

• 2cc2219 v2.3.1
• bc4ae2f Ginkgo cli can identify version mismatches and emit a helpful error message
• 2691dd8 further emphasize that a version match is required when running Ginkgo on CI ...
• 822a937 bump gomega to v1.22.0
• 87fc2ec v2.3.0
• bda6ffe clarify what we mean by cleanup nodes
• b182b1f document how SpecContext and Eventually work together
• 5ddc567 be more consistent about 'Timedout' vs 'Timeout'
• a87ec82 Gingko now records additional failures that occur during cleanup of a failed ...
• cd395fc ensure post-timeout failure makes it into the JUnit report
• 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)

[kubevirt-bot]

Hi @dependabot[bot]. Thanks for your PR.

I'm waiting for a kubevirt member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[mfranczy]

/ok-to-test

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mfranczy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/kubevirt/cloud-provider-kubevirt/blob/main/OWNERS)~~ [mfranczy] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[kubevirt-bot]

New changes are detected. LGTM label has been removed.

[dependabot[bot]]

Superseded by #175.