This orders reusable containers on wish and is meant for scenarios in which a CI does not allow "native" use of reusable test containers but will make sure to clean them up after CI ran. Export a variable `SDN_FORCE_REUSE_OF_CONTAINERS` as `true` and SDN tests won't close the container, regardless whether the underlying Testcontainers supports reuse or not.
Closes#2837
This change publishes a build scan to ge.spring.io for every local build from an authenticated Spring committer and for CI where appropriate access tokens are available. The build will not fail if publishing fails.
This change also allows the build to benefit from local and remote build caching, providing faster builds for all contributors.
Additionally, the project will have access to all features of Gradle Enterprise such as:
- Dashboards to view all historical build scans, along with performance trends over time
- Build failure analytics for enhanced investigation and diagnosis of build failures
- Test failure analytics to better understand trends and causes around slow, failing, and flaky tests
See #2811
See update to the original ticket:
> It turns out that a couple of aspects we need in setting up this scripts
> are very specific to our internal testing. Therefore, the scripts should
> live in a separate project.
>
> I do think that would also make complete sense for VMWares CI scripts
> and thus keeping that repo free of CI specific scripts, but this is
> maybe another ticket. Our scripts will be removed in an additional
> commit.
We must ensure that SDN 6 runs successfully against cluster deployments.
Our bookmark code is already under tests (explicitly via the JUnit 5 Neo4j cluster extension) under load.
However, we should run the whole test suite, too.
This change does the following
- Provide additional selectors that can exclude tests that made no sense in a cluster environment
- Seed all tests with the bookmarks from the fixtures
- Capture the bookmarks after the test and assert with them as starting point
- Provide additional Ci scripts to run them in a controlled manner, providing retries to react on cluster failures during tests, much like application developers would do.
This closes#2245.