kurtosis-tech · adschwartz · Aug 24, 2023 · Aug 24, 2023 · Aug 24, 2023
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,5 +1,17 @@
 # Changelog
 
+## [0.82.2](https://github.com/kurtosis-tech/kurtosis/compare/0.82.1...0.82.2) (2023-08-24)
+
+
+### Features
+
+* make paths relative to support embedding in other contexts ([#1151](https://github.com/kurtosis-tech/kurtosis/issues/1151)) ([74fbe53](https://github.com/kurtosis-tech/kurtosis/commit/74fbe53c07e1dd0c2ae994e2246d1b7033b1bad3))
+
+
+### Bug Fixes
+
+* lower calls to backend by doing get all services more efficiently ([#1143](https://github.com/kurtosis-tech/kurtosis/issues/1143)) ([a2c0dcc](https://github.com/kurtosis-tech/kurtosis/commit/a2c0dcc0bc3874338ac6fbd5c42bf45163a628dc)), closes [#1074](https://github.com/kurtosis-tech/kurtosis/issues/1074)
+
 ## [0.82.1](https://github.com/kurtosis-tech/kurtosis/compare/0.82.0...0.82.1) (2023-08-23)
 
 

diff --git a/LICENSE.md b/LICENSE.md
@@ -3,7 +3,7 @@ Business Source License 1.1
 Parameters
 
 Licensor:             Kurtosis Technologies, Inc.
-Licensed Work:        Kurtosis 0.82.1
+Licensed Work:        Kurtosis 0.82.2
 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.
@@ -12,7 +12,7 @@ you may not use the Licensed Work for an Environment Orchestration Service.
                       allows third parties (other than your employees and
                       contractors) to create distributed system environments.
 
-Change Date:          2027-08-23
+Change Date:          2027-08-24
 
 Change License:       AGPLv3 (GNU Affero General Public License Version 3)
 

diff --git a/api/golang/kurtosis_version/kurtosis_version.go b/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.82.1"
+	KurtosisVersion = "0.82.2"
 	// !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!
 )
diff --git a/api/rust/Cargo.toml b/api/rust/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "kurtosis-sdk"
-version = "0.82.1"
+version = "0.82.2"
 license = "BUSL-1.1"
 description = "Rust SDK for Kurtosis"
 edition = "2021"

diff --git a/api/typescript/package.json b/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.82.1",
+    "version": "0.82.2",
     "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",

diff --git a/api/typescript/src/kurtosis_version/kurtosis_version.ts b/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.82.1"
+export const KURTOSIS_VERSION: string = "0.82.2"
 // !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!
diff --git a/docs/versioned_docs/version-0.82.2/best-practices.md b/docs/versioned_docs/version-0.82.2/best-practices.md
@@ -0,0 +1,57 @@
+---
+title: Best Practices
+sidebar_label: Best Practices
+slug: /best-practices
+---
+
+Passing package arguments to the CLI
+-------------------------------
+Passing [package parameters][package-parameterization] via 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-params.json)"
+   ```
+   The double quotes around the `$(cat my-params.json)` are important so any spaces inside `my-params.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`
+
+Choosing service names in Kurtosis
+----------------------------------
+Kurtosis service names implements [RFC-1035](https://datatracker.ietf.org/doc/html/rfc1035), meaning the names of all services must be a valid [RFC-1035 Label Name](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names). Tactically this means a service name must:
+
+- contain at most 63 characters
+- contain only lowercase alphanumeric characters or '-'
+- start with an alphabetic character
+- end with an alphanumeric character
+
+Failure to adhere to the above standards will result in errors when running Kurtosis.
+
+
+
+<!---------------------------------------- ONLY LINKS BELOW HERE!!! ----------------------------------->
+[package-parameterization]: ./concepts-reference/packages.md#parameterization
+
+[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