chore(main): release 0.78.3

CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## [0.78.3](https://github.com/kurtosis-tech/kurtosis/compare/0.78.2...0.78.3) (2023-06-13)
+
+
+### Features
+
+* Remove `--exec` flag for `kurtosis service shell` ([#712](https://github.com/kurtosis-tech/kurtosis/issues/712)) ([d8bc320](https://github.com/kurtosis-tech/kurtosis/commit/d8bc3206be4ec3d6dec7973c3b31f8746b6089d3))
+
+
+### Bug Fixes
+
+* add `continue` to avoid segfault on service failing to register ([#719](https://github.com/kurtosis-tech/kurtosis/issues/719)) ([0cebb1f](https://github.com/kurtosis-tech/kurtosis/commit/0cebb1fe22ffd0e0e5e532164c3b0ef658b3ee55))
+
 ## [0.78.2](https://github.com/kurtosis-tech/kurtosis/compare/0.78.1...0.78.2) (2023-06-13)
 
 

LICENSE.md

@@ -3,7 +3,7 @@ Business Source License 1.1
 Parameters
 
 Licensor:             Kurtosis Technologies, Inc.
-Licensed Work:        Kurtosis 0.78.2
+Licensed Work:        Kurtosis 0.78.3
 The Licensed Work is (c) 2023 Kurtosis Technologies, Inc.
 Additional Use Grant: You may make use of the Licensed Work, provided that
 you may not use the Licensed Work for an Environment Orchestration Service.

api/golang/kurtosis_version/kurtosis_version.go

@@ -9,6 +9,6 @@ const (
 	// !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!
 	// This is necessary so that Kurt Core consumers will know if they're compatible with the currently-running
 	//  API container
-	KurtosisVersion = "0.78.2"
+	KurtosisVersion = "0.78.3"
 	// !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!
 )

api/typescript/package.json

@@ -1,7 +1,7 @@
 {
     "name": "kurtosis-sdk",
     "//": "NOTE: DO NOT UPDATE THIS VERSION MANUALLY - IT WILL BE UPDATED DURING THE RELEASE PROCESS!",
-    "version": "0.78.2",
+    "version": "0.78.3",
     "main": "./build/index",
     "description": "This repo contains a Typescript client for communicating with the Kurtosis Engine server, which is responsible for creating, managing and destroying Kurtosis Enclaves.",
     "types": "./build/index",

api/typescript/src/kurtosis_version/kurtosis_version.ts

@@ -1,5 +1,5 @@
 // !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!
 // This is necessary so that Kurt Core consumers (e.g. modules) will know if they're compatible with the currently-running
 //  API container
-export const KURTOSIS_VERSION: string = "0.78.2"
+export const KURTOSIS_VERSION: string = "0.78.3"
 // !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!

docs/versioned_docs/version-0.78.3/best-practices.md

@@ -0,0 +1,44 @@
+---
+title: Best Practices
+sidebar_label: Best Practices
+slug: /best-practices
+---
+
+Passing package arguments to the CLI
+-------------------------------
+Passing [package arguments][args-concepts-reference] to the CLI can get hairy due to the interaction between Bash and JSON quotes. The following are tips to make your life easier:
+
+1. **When you have a small number of arguments:** surround the arguments with single quotes so you don't have to escape double quotes in your JSON. E.g.:
+   ```bash
+   kurtosis run github.com/user/repo '{"some_param":5,"some_other_param":"My value"}'
+   ```
+1. **When you have a large number of arguments:** put them in a `.json` file and use [Bash command substitution](https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html) _inside double quotes_ to slot them into the `kurtosis run` command. E.g.:
+   ```bash
+   kurtosis run github.com/user/repo "$(cat my-args.json)"
+   ```
+   The double quotes around the `$(cat my-args.json)` are important so any spaces inside `my-args.json` don't fool Bash into thinking you're passing in two separate arguments.
+
+Choosing the right wait
+-----------------------
+Kurtosis has three different types of waits. Described here are the three, with tips on when to use each:
+
+1. Automatic waiting on port availability when a service starts (enabled by default; can be configured with [`PortSpec.wait`][port-spec-starlark-reference])
+    - Should be sufficient for most usecases
+    - Requires little-to-no extra configuration
+    - Will cause parallel `Plan.add_services` to fail, allowing for quick aborting
+1. Waiting on [`ReadyCondition`][ready-condition-starlark-reference]s (configured in [`ServiceConfig`][service-config-starlark-reference])
+    - Allows for more advanced checking (e.g. require a certain HTTP response body, ensure a CLI call returns success, etc.)
+    - More complex to configure
+    - Will cause parallel `Plan.add_services` to fail, allowing for quick aborting
+1. The [`Plan.wait`][plan-wait-starlark-reference]
+    - Most useful for asserting the system has reached a desired state in tests (e.g. wait until data shows up after loading)
+    - More complex to configure
+    - Cannot be used to short-circuit `Plan.add_services`
+
+<!---------------------------------------- ONLY LINKS BELOW HERE!!! ----------------------------------->
+[args-concepts-reference]: ./concepts-reference/args.md
+
+[service-config-starlark-reference]: ./starlark-reference/service-config.md
+[port-spec-starlark-reference]: ./starlark-reference/port-spec.md
+[ready-condition-starlark-reference]: ./starlark-reference/ready-condition.md
+[plan-wait-starlark-reference]: ./starlark-reference/plan.md#wait