The latest release is `0.80.3`. For a more detailed changelog, visit our [docs](https://docs.kurtosis.com/changelog).
# Breaking Changes
- [0.80.0] As a result of [`RFC-123`](https://datatracker.ietf.org/doc/html/rfc1123) standard adoption, we have made changes to the naming convention for services to ensure compatibility when deploying services on Kubernetes. This update is a follow-up to issue [#713](https://github.com/kurtosis-tech/kurtosis/pull/713). The primary modification involves applying the [`RFC-123`](https://datatracker.ietf.org/doc/html/rfc1123)standard to service names. By conforming to this standard, we ensure compatibility and proper functioning when launching services on Kubernetes. We have implemented this change across all packages in `awesome-kurtosis` as well as the packages referenced within it. Additionally, we have addressed the noncompliant naming standards in a few packages.
[#749](https://github.com/kurtosis-tech/kurtosis/pull/749)
- [0.79.0] We made several changes regarding the `workdir` parameter in the `run_sh` command and addressed related typos in our documentation. Now, the shell command executed will either run from the root directory or from the `workdir` set in the image. Consequently, file artifacts can only be accessed using absolute paths instead of relative paths. Previously, the result of `plan.run_sh(...)` would return `result.file_artifacts`, but we have rectified the typo for consistency, and it now returns `result.files_artifacts`, providing a way to access the file artifacts from the task. Users should update their Starlark package to ensure compatibility with the latest version of Kurtosis and remove any references to the `workdir` parameter, as it has been removed. The command executed by [`run_sh`](https://docs.kurtosistech.com/starlark-reference/plan/#run_sh) will now utilize the default working directory. [#739](https://github.com/kurtosis-tech/kurtosis/pull/739)
# Features
- [0.80.3] The APIC (Application Programming Interface Controller) has been enhanced to include limited functionality for feature flags. This improvement introduces an `--experimental` flag to the `kurtosis run` command, providing the ability to selectively enable experimental features while executing a Starlark package.
[#775](https://github.com/kurtosis-tech/kurtosis/pull/775)
- [0.80.3] Added a new feature to the command-line interface (CLI) that allows users to easily retrieve information about a specific port. The command `kurtosis port print enclave-id service-id port-id` can be used to access details such as the port's accessibility. This functionality provides users with a convenient way to quickly check how to access a specific port.
[#778](https://github.com/kurtosis-tech/kurtosis/pull/778)
- [0.80.3] We have introduced a new feature called "idempotent run v0" that helps improve the execution of tasks in a simpler way. This feature saves the current status of a particular process after each execution and optimizes subsequent runs by only performing the steps that have changed since the last run. In this initial version, the optimization is done in an "append-only" manner, which means that any changes made will only affect the instructions added at the end of the task list. This helps make the execution faster and more efficient, ultimately improving the overall experience.
[#769](https://github.com/kurtosis-tech/kurtosis/pull/769)
- [0.80.3] The CLI now includes support for stopping and starting services, providing a convenient way to manage service execution. Previously, it was only possible to stop and start services using the Starlark instructions `plan.stop_service` and `plan.start_service`. With this update, users can utilize the `service stop` and `service start` commands in the command-line interface (CLI). These commands require inputs such as the enclave identifier and service identifier, similar to the existing `service logs` and `service rm` commands. Additionally, the CLI documentation section has been updated to reflect these changes, and two basic CLI tests have been added to the continuous integration (CI) process.
[#767](https://github.com/kurtosis-tech/kurtosis/pull/767)
- [0.80.2] We've added a new Rust SDK, which includes a generated protobuf for seamless interaction with AWS services. The Rust SDK is compiled as part of the build process, and any changes made to the protobufs can be easily incorporated by running the `./api/scripts/regenerate-protobuf-bindings.sh` command and committing the updated files to git. This eliminates the need to write additional Rust code, allowing you to focus on your application's core business logic and simplifying the process of working with AWS services.
[#765](https://github.com/kurtosis-tech/kurtosis/pull/765)
- [0.80.1] An enhancement has been made to the system by adding a new field called "wait" to the run_sh task. This new field serves the purpose of allowing users to specify a time-out period. If the command specified in the [run_sh](https://docs.kurtosistech.com/starlark-reference/plan/#run_sh) task exceeds the defined time-out period, it will be treated as a failure. In addition, this update includes a bug fix related to the wait and ready-condition functionality within the exec-recipe when operating in a Kubernetes (k8s) environment. [#750](https://github.com/kurtosis-tech/kurtosis/pull/750)
- [0.80.1] The Starlark executor now maintains a record of all instructions executed within a given enclave, thereby adding an important layer of traceability and accountability. This can significantly aid debugging, issue resolution, and procedural compliance. However, it's worth noting that this tracking system does not account for manual modifications such as manual file uploads done via the command-line interface (CLI). [#757](https://github.com/kurtosis-tech/kurtosis/pull/757)
- [0.80.0] We've added the ability to stop and start services using Starlark for Kubernetes (k8s) [#756](https://github.com/kurtosis-tech/kurtosis/pull/756). Most of the work for the Kubernetes (k8s) backend was done as part of [#694](https://github.com/kurtosis-tech/kurtosis/pull/694). In addition, the port forwarder reconnect feature reduced the amount of work we had to finish. Here are the changes made:
* We keep the K8S service untouched when we stop the user service so it can be restarted easily by creating a new pod. This change does not impact the remove service expected behavior.
* We don't try to create a port forwarder connection if the service is stopped.
- [0.79.0] Users can now easily open a [Shell](https://docs.kurtosis.com/service-shell/) on a container running in Kubernetes (k8s) using a single Kurtosis command. This functionality was previously exclusive to Docker, but now it is available on both platforms. Open a Shell - `sh` into the container running the service refers to opening an interactive command-line interface inside the container. It grants direct access and control over the service's environment for troubleshooting and executing commands.
[#748](https://github.com/kurtosis-tech/kurtosis/pull/748)
# Bug Fixes
- [0.79.0] We've added reconnect logic to the gateway port forwarder. This means that the system will attempt to reestablish the connection automatically in case of network interruptions. The reconnection attempts will stop when a service is removed either through the [removeservice](https://docs.kurtosis.com/starlark-reference/plan/#remove_service) command or via a Starlark script. This improvement aims to provide a more robust and seamless experience by handling network disruptions without requiring manual intervention or restarting the Gateway.
[#736](https://github.com/kurtosis-tech/kurtosis/pull/736)