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())
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]
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())
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]
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)
Bumps github.com/onsi/ginkgo/v2 from 2.2.0 to 2.3.1.
Release notes
Sourced from github.com/onsi/ginkgo/v2's releases.
Changelog
Sourced from github.com/onsi/ginkgo/v2's changelog.
Commits
2cc2219
v2.3.1bc4ae2f
Ginkgo cli can identify version mismatches and emit a helpful error message2691dd8
further emphasize that a version match is required when running Ginkgo on CI ...822a937
bump gomega to v1.22.087fc2ec
v2.3.0bda6ffe
clarify what we mean by cleanup nodesb182b1f
document how SpecContext and Eventually work together5ddc567
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 reportDependabot 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)