**New here?** [Testkube](https://testkube.io) is a Kubernetes-native testing framework for testers and developers. It acts as an executor so you can orchestrate, run, and display tests and test results for your code in a Kubernetes environment. Whether you're new to the K8s ecosystem or a seasoned pro, Testkube lets you focus on testing without having to complicate yourself, your processes, or your pipelines.
Testkube v1.8 is now live. This release includes big improvements for logging, AWS S3 support, and test container artifacts. Read on to get all the deets.
Test Container Artifacts
If you’d like to implement a container executor for a testing tool that produces files, it’s now possible to collect and store the artifacts for your Custom Container Executors in our S3 compatible file storage.
To access them, you’ll need to save the output files into specific directories, and they’ll be uploaded to Testkube’s file storage - which will make them available for download through the CLI:
kubectl testkube get artifact artifactid
…or through Testkube’s UI!
To read more about this feature, check out the [implementation docs.](https://kubeshop.github.io/testkube/test-types/container-executor/#collecting-test-artifacts)
AWS S3 Support
You can now use AWS S3 for storage using IAM authentication!
To set it up, you’ll need to install Testkube using Helm and create your ServiceAccount (specifying your Amazon Resource Name).
Link your account to `testkube-api.minio.serviceAccountName` and `testkube-api.jobServiceAccountName` in the Helm values.yaml file, leave `minio.minioRootUser`, `minio.minioRootPassword`and `storage.port` empty, also set `storage.endpoint` to `s3.amazonaws.com`.
Slack Template and Events Customization
It’s now possible to customize the message template that is used for your Testkube Slack notifications. We’ve also worked on making it easier and more flexible to configure Events, Test Names, Test Suites and Channels.
Job Template Extensions
You can now adjust the definition of job templates with different parameters.
To do this, Testkube allows you to add them as extensions with the additional parameter `--job-template` when you create or run your tests.
kubectl testkube create test --git-branch main --git-uri https://github.com/kubeshop/testkube-example-cypress-project.git --git-path "cypress" --name template-test --type cypress/project --job-template job.yaml
Your `job.yaml` file should contain the adjusted job template so it can be merged with the default one.
Read more about how to do this in [our docs](https://kubeshop.github.io/testkube/using-testkube/tests/tests-creating/#changing-the-default-job-template-used-for-test-execution).
Have Your Tests Dynamically Fetch Files From Your Branches
When running your tests through Testkube CLI using the `testkube run test` CLI command, you can now add specific parameters that will allow for Testkube to dynamically check out the appropriate branches you need.
To adjust this, you can use `--git-branch`, `--git-commit`, `--git-path`, or `--git-working-dir`.
Check all the details in our [documentation](https://kubeshop.github.io/testkube/cli-reference/testkube_run_test/#testkube-run-test).
Patching Mode Update
We introduced a new API method and updated the CLI command to patch only specific fields when creating and updating tests.
SSL Support for External MongoDB Connections
Testkube allows you to configure SSL certificates for MongoDB now - this should help you and your teams to store test results in your local or centralized database.
To set it up, refer to our [SSL connections](https://kubeshop.github.io/testkube/using-testkube/dependencies/#ssl-connections) documentation.
Large, Optimized File Uploads
You’ll now be able to map local files to your Testkube tests, no matter how large they are. Your files will be copied upon execution from the machine running **kubectl**, and available in the `/data/uploads` folder inside your test container.
To do this, pass the file in the format `source_path:destination_path` using the flag `--copy-files`.
Check our [documentation](https://github.com/kubeshop/testkube/issues/2594) for more on this.
Private Image Registries
Now everyone can deploy Testkube using their own image registries!
We have added an option to redefine registries globally for the whole chart. Moreover, the external charts that we use (NATS and MongoDB) also support registry parameters - so it’s possible to use Testkube with defined security measurements.
What’s Next: more transparent logging
No more time spent in confusion trying to figure out what’s going on with your tests - we’ll work on improving logging so you know what’s happening at all times and through every step of the testing process.
We wouldn’t be here without you - for this release, we’d like to highlight a few of our contributors for their suggestions, feedback, and feature requests:
Thank you for helping us make Testkube better.
Interested in seeing how it all works? Catch the Testkube team’s demo on the v1.8 release through our livestream [here](https://www.youtube.com/watch?v=0JE5x6Rrp9M).
Give it a go
Feel free to have a look at the new updates available and let us know what you think or how to make Testkube better! We’ve got a [great demo](https://demo.testkube.io/) you can play with and you can download the release from [GitHub](https://github.com/kubeshop/testkube).
If you’d like more info, or just to come say ‘Hi’ – join our [Discord server](https://discord.gg/hfq44wtR6Q) and follow us on Twitter [@Testkube_io](http://twitter.com/testkube_io). You can also email our Product Leader directly at [firstname.lastname@example.org](mailto:email@example.com). We’re looking forward to hearing from you.