Merge branch 'main' into gyani/description

CHANGELOG.md

@@ -1,5 +1,26 @@
 # Changelog
 
+## [0.86.22](https://github.com/kurtosis-tech/kurtosis/compare/0.86.21...0.86.22) (2024-02-15)
+
+
+### Bug Fixes
+
+* allow building images in arm64 ([#2161](https://github.com/kurtosis-tech/kurtosis/issues/2161)) ([acd884f](https://github.com/kurtosis-tech/kurtosis/commit/acd884fb1a8292b450e66c8f48156f4cef52a082))
+
+## [0.86.21](https://github.com/kurtosis-tech/kurtosis/compare/0.86.20...0.86.21) (2024-02-15)
+
+
+### Bug Fixes
+
+* Core image builds for arm64 under CI ([#2149](https://github.com/kurtosis-tech/kurtosis/issues/2149)) ([807ddae](https://github.com/kurtosis-tech/kurtosis/commit/807ddae12b9274819f53160a8771da7541f4a4c1))
+
+## [0.86.20](https://github.com/kurtosis-tech/kurtosis/compare/0.86.19...0.86.20) (2024-02-14)
+
+
+### Features
+
+* support `run_sh` and `exec` in enclave builder ([#2158](https://github.com/kurtosis-tech/kurtosis/issues/2158)) ([f784eaf](https://github.com/kurtosis-tech/kurtosis/commit/f784eaf7a24ae282aa470d22e6a9ad721d04cc05))
+
 ## [0.86.19](https://github.com/kurtosis-tech/kurtosis/compare/0.86.18...0.86.19) (2024-02-09)
 
 

LICENSE.md

@@ -3,7 +3,7 @@ Business Source License 1.1
 Parameters
 
 Licensor:             Kurtosis Technologies, Inc.
-Licensed Work:        Kurtosis 0.86.19
+Licensed Work:        Kurtosis 0.86.22
 The Licensed Work is (c) 2024 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:          2028-02-09
+Change Date:          2028-02-15
 
 Change License:       Apache 2.0 (Apache License, Version 2.0)
 

README.md

@@ -1,35 +1,40 @@
 
 <img src="./readme-static-files/logo.png" width="1200">
 
+[![Follow us on X, formerly Twitter](https://img.shields.io/twitter/follow/KurtosisTech?style=social)](https://twitter.com/Kurtosistech)
+[![Number of GitHub stars](https://img.shields.io/github/stars/kurtosis-tech/kurtosis)](https://github.com/kurtosis-tech/kurtosis/stargazers)
+
 ----
 
 What is Kurtosis?
 =================
-[Kurtosis](https://www.kurtosis.com) is a platform for packaging and launching environments of containerized services ("distributed applications") with a focus on approachability for the average developer. What Docker did for shipping binaries, Kurtosis aims to do even better for distributed applications. 
+
+Have you ever tried to build on top of a colleague's work, or contribute to an open source project, just to get stuck on the first steps of spinning up a stack to play with? [Kurtosis](https://www.kurtosis.com) handles the complexity of spinning up ephemeral dev or test stacks so you can focus on developing, not configuring.
 
 Kurtosis is formed of:
+- A packaging system for distributing backend stack definitions, which can run on docker or on kubernetes
+- A runtime with a per-stack file management system for reproducibly initializing the state of your stack
+- A set of tools to enable devs to interact with their stacks, like they do on docker or k8s
 
-- A language for declaring a distributed application in Python syntax ([Starlark](https://github.com/google/starlark-go/blob/master/doc/spec.md))
-- A packaging system for sharing and reusing distributed application components
-- A runtime that makes a Kurtosis app Just Work, independent of whether it's running on Docker or Kubernetes, local or in the cloud
-- A set of tools to ease common distributed app development needs (e.g. a log aggregator to ease log-diving, automatic port-forwarding to ease connectivity, a `kurtosis service shell` command to ease container filesystem exploration, etc.)
+Why use Kurtosis?
+=========================
 
-Why should I use Kurtosis?
-==========================
-Kurtosis shines when creating, working with, and destroying self-contained distributed application environments. Currently, our users report this to be most useful when:
+Kurtosis is best for:
 
-- You're developing on your application and you need to rapidly iterate on it
-- You want to try someone's containerized service or distributed application without setting up an environment, dependencies, etc.
-- You want to spin up your distributed application in ephemeral environments as part of your integration tests
-- You want to ad-hoc test your application on a big cloud cluster
-- You're the author of a containerized service or distributed application and you want to give your users a one-liner to try it
-- You want to get an instance of your application running in the cloud without provisioning or administering a Kubernetes cluster
+- Reusing the logic in your stack definitions for all of: local dev, scheduled testing in CI, and ad-hoc larger-scale testing on k8s clusters
+- Giving other devs a way to spin up your application, and commonly used variations of it, with one-liners, via Kurtosis' packaging and parameterization systems
+- Handling complex setup logic in your backend stack, like passing arbitrary data between services as they start up, and enforcing arbitrary wait conditions
 
-If you're in web3, we have even more specific web3 usecases [here](https://web3.kurtosis.com).
+How is Kurtosis different than Docker Compose or Helm?
+==========================
 
-Check out an introductory demo video here:
+Kurtosis operates at a level higher than Docker Compose or Helm, and produces stacks running on either of the underlying engines (the Docker engine, or Kubernetes).
+Because of this additional layer of abstraction, we are able to introduce several features to improve the experience of spinning up ephemeral stacks:
 
-<video width="630" height="300" src="https://github.com/kurtosis-tech/kurtosis/assets/11703004/f908aa4a-b340-44c8-b948-46993dcdb96e"></video>
+- A per-stack file management system that enables portable state initialization for dev or test stacks
+- Stack-level parameterizability; users have a powerful and flexible way (beyond messing with env vars) to affect modifications in their stacks
+- First-class plug-and-play composability; it's expected for users to import stack definitions into larger stacks, and this experience is optimized
+- The ability to get all of the above, but running over _either_ the docker engine or k8s, at your election
 
 How do I get going?
 ===================
@@ -53,11 +58,7 @@ If you have an issue or feature request, we'd love to hear about it through one
 
 ### Going further
 
-To try more Kurtosis packages just like this one, check out the [`awesome-kurtosis` repo][awesome-kurtosis] or one of these packages:
-
-- [Ethereum](https://github.com/kurtosis-tech/ethereum-package): fully functional private Ethereum network in Kurtosis with Flashbots MEV-boost, any EL and CL client combination, and a collection of network monitoring tools.
-- [DIVE](https://github.com/HugoByte/DIVE): A CLI + Kurtosis package by [Hugobyte](https://hugobyte.com) for the ICON ecosystem that can spin up EVM, Cosmos, or JVM networks with a bridge between them.
-- [NEAR](https://github.com/kurtosis-tech/near-package): A private NEAR network in Kurtosis.
+To try more Kurtosis packages just like this one, check out the [`awesome-kurtosis` repo][awesome-kurtosis]! 
 
 To learn about how to write Kurtosis packages, check out our [quickstart][quickstart-reference].
 
@@ -67,40 +68,6 @@ To see where we're going with the product, check out the roadmap [here](https://
 
 Got more questions? Drop them in our [Github Discussions](https://github.com/kurtosis-tech/kurtosis/discussions/new?category=q-a) where we, or other community members, can help answer.
 
-Why Kurtosis over Compose, Helm, or Terraform?
-==============================================
-These tools have been around for over a decade, yet most developers still struggle to build distributed applications. Why? In a sentence: building distributed applications is hard, and these tools still haven't made it easy enough for the average developer.
-
-Some of our observations:
-
-- No tool works across the whole software lifecycle: Compose is oriented around quick local environments rather than Prod environments, while Helm and Terraform are the opposite. This often means a dedicated DevOps team handles Prod deployment, leading to the same "throw it across the wall" problem the DevOps movement was founded around.
-- Compose, Helm, and Terraform use fully declarative paradigms, making difficult the sequential "first this, then this" logic necessary for many prototyping workflows.
-- The inherently declarative nature of all three make [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) difficult, leading to frequent copy-pasting.
-- All three tend to leave resources hanging around that the developer needs to manually clean up.
-- Compose and Helm favor "run it and see what happens" over validation & error-checking, resulting in debugging time and longer dev cycles.
-- A significant percentage of developers don't understand how Docker works, and [most don't understand Kubernetes or Terraform][stackoverflow-2022-developer-survey--other-tools].
-
-Here's what our users tell us they like about Kurtosis:
-
-- **It's understandable:** you write code in Python syntax, and you get your distributed application the other side. Variables and functions keep your code DRY.
-- **It's portable:** your application runs with a one-liner independent of where you run it. You can build your application on your local Docker, and in seconds get the same thing on your friend's laptop or a Kubernetes cluster in the cloud.
-- **It can handle sequential dependencies:** for example, "first generate these files, then use them when starting a service".
-- **It's reliable and reproducible:** Kurtosis started as a testing tool and is built to be safe: deterministic execution order, validation to catch errors before runtime, built-in support for inter-service dependencies and readiness checks, etc. Your distributed app should spin up the same way, every time.
-- **It abstracts away complexity while being configurable:** instantiating a distributed application is as simple as calling its function with the parameters you want. For example, instantiating a Postgres server with modified username and password:
-
-  On the CLI...
-  ```bash
-  kurtosis run github.com/kurtosis-tech/postgres-package '{"user": "bobmarley", "password": "buffalosoldier"}'
-  ```
-
-  Inside an environment definition...
-  ```python
-  postgres = import_module("github.com/kurtosis-tech/postgres-package/main.star")
-
-  def run(plan):
-    postgres.run(plan, user = "bobmarley", password = "buffalosoldier")
-  ```
-
 Contributing to Kurtosis
 ========================
 

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.86.19"
+	KurtosisVersion = "0.86.22"
 	// !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!
 )

api/rust/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "kurtosis-sdk"
-version = "0.86.19"
+version = "0.86.22"
 license = "BUSL-1.1"
 description = "Rust SDK for Kurtosis"
 edition = "2021"

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.86.19",
+    "version": "0.86.22",
     "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.86.19"
+export const KURTOSIS_VERSION: string = "0.86.22"
 // !!!!!!!!!!! DO NOT UPDATE! WILL BE MANUALLY UPDATED DURING THE RELEASE PROCESS !!!!!!!!!!!!!!!!!!!!!!

core/server/Dockerfile

@@ -2,7 +2,12 @@ FROM alpine:3.17
 
 # We need protobut-dev to run protobuf compiler against startosis .proto files
 RUN apk update && apk add --no-cache bash protobuf-dev sudo shadow curl xz
-RUN sh <(curl -L https://nixos.org/nix/install) --daemon --yes
+
+# Install Nix
+# We need to set filter-syscalls to false to allow Nix install to work properly inside a container with cross platform emulation
+# via QEMU: https://github.com/NixOS/nix/issues/5258 and use a more flexible installer https://github.com/DeterminateSystems/nix-installer
+# with a workaround on the same issue: https://github.com/DeterminateSystems/nix-installer/issues/324)
+RUN curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install linux --no-confirm --init none --extra-conf "filter-syscalls = false"
 
 ARG TARGETARCH
 

core/server/Dockerfile.debug

@@ -2,7 +2,12 @@ FROM alpine:3.19
 
 # We need protobut-dev to run protobuf compiler against startosis .proto files
 RUN apk update && apk add --no-cache bash protobuf-dev sudo shadow curl xz
-RUN sh <(curl -L https://nixos.org/nix/install) --daemon --yes
+
+# Install Nix
+# We need to set filter-syscalls to false to allow Nix install to work properly inside a container with cross platform emulation
+# via QEMU: https://github.com/NixOS/nix/issues/5258 and use a more flexible installer https://github.com/DeterminateSystems/nix-installer
+# with a workaround on the same issue: https://github.com/DeterminateSystems/nix-installer/issues/324)
+RUN curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install linux --no-confirm --init none --extra-conf "filter-syscalls = false"
 
 # Make sure that you changed the port inside the APIC's code before changing it here
 EXPOSE 50103

docs/docs/api-reference/starlark-reference/plan.md

@@ -557,15 +557,15 @@ The instruction returns a `struct` with [future references][future-references-re
         ..., 
         config=ServiceConfig(
             name="service_one", 
-            files={"/src": results.file_artifacts[0]}, # copies the directory task into service_one 
+            files={"/src": result.file_artifacts[0]}, # copies the directory task into service_one 
         )
     ) # the path to the file will look like: /src/task/test.txt
 
     service_two = plan.add_service(
         ..., 
         config=ServiceConfig(
             name="service_two", 
-            files={"/src": results.file_artifacts[1]}, # copies the file test.txt into service_two
+            files={"/src": result.file_artifacts[1]}, # copies the file test.txt into service_two
         ),
     ) # the path to the file will look like: /src/test.txt
 ```

docs/docs/api-reference/starlark-reference/service-config.md

@@ -73,8 +73,10 @@ config = ServiceConfig(
         flake_output = "containerImage",
     )
 
-    # The ports that the container should listen on, identified by a user-friendly ID that can be used to select the port again in the future.
-    # If no ports are provided, no ports will be exposed on the host machine, unless there is an EXPOSE in the Dockerfile
+    # The ports that the container should listen on, identified by a user-friendly ID that can be used to select the port again in the future.      
+    # Kurtosis will automatically perform a check to ensure all declared UDP and TCP ports are open and ready for traffic and connections upon startup.
+    # You may specify a custom wait timeout duration or disable the feature entirely, learn more via PortSpec docs
+    # If no ports are provided, no ports will be exposed on the host machine, unless there is an EXPOSE in the Dockerfile.
     # OPTIONAL (Default: {})
     ports = {
         "grpc": PortSpec(

docs/docs/guides/running-docker-compose.md

@@ -73,7 +73,7 @@ kurtosis run .
 ```
 OR using github link:
 ```
-kurtosis run github.com/awesome-compose/nextcloud-redis-mariadb
+kurtosis run github.com/docker/awesome-compose/nextcloud-redis-mariadb
 ```
 
 Behind the scenes, Kurtosis will interpret your Docker Compose setup as a Kurtosis [package](../get-started/basic-concepts.md#package) and convert it into [starlark](../advanced-concepts/starlark.md) that is executed on an [enclave](../get-started/basic-concepts.md#enclave). The output will look like this:

docs/yarn.lock

@@ -4147,9 +4147,9 @@ flux@^4.0.1:
     fbjs "^3.0.1"
 
 follow-redirects@^1.0.0, follow-redirects@^1.14.7:
-  version "1.15.0"
-  resolved "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.0.tgz"
-  integrity sha512-aExlJShTV4qOUOL7yF1U5tvLCB0xQuudbf6toyYA0E/acBNw71mvjFTnLaRp50aQaYocMR0a/RMMBIHeZnGyjQ==
+  version "1.15.4"
+  resolved "https://registry.yarnpkg.com/follow-redirects/-/follow-redirects-1.15.4.tgz#cdc7d308bf6493126b17ea2191ea0ccf3e535adf"
+  integrity sha512-Cr4D/5wlrb0z9dgERpUL3LrmPKVDsETIJhaCMeDfuFYcqa5bldGV6wBsAN6X/vxlXQtFBMrXdXxdL8CbDTGniw==
 
 fork-ts-checker-webpack-plugin@^6.5.0:
   version "6.5.2"

enclave-manager/web/lerna.json

@@ -1,6 +1,6 @@
 {
   "packages": ["packages/*"],
-  "version": "0.86.19",
+  "version": "0.86.22",
   "npmClient": "yarn",
   "$schema": "node_modules/lerna/schemas/lerna-schema.json",
   "useNx": false,

enclave-manager/web/packages/app/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kurtosis/emui-app",
-  "version": "0.86.19",
+  "version": "0.86.22",
   "private": true,
   "homepage": ".",
   "dependencies": {
@@ -10,7 +10,7 @@
     "html-react-parser": "^4.2.2",
     "js-cookie": "^3.0.5",
     "kurtosis-cloud-indexer-sdk": "^0.0.2",
-    "kurtosis-ui-components": "0.86.19",
+    "kurtosis-ui-components": "0.86.22",
     "react-error-boundary": "^4.0.11",
     "react-hook-form": "^7.47.0",
     "react-mentions": "^4.4.10",

enclave-manager/web/packages/app/src/emui/enclaves/components/form/CodeEditorInput.tsx

@@ -0,0 +1,43 @@
+import { CodeEditor } from "kurtosis-ui-components";
+import { Controller } from "react-hook-form";
+import { FieldPath, FieldValues } from "react-hook-form/dist/types";
+import { ControllerRenderProps } from "react-hook-form/dist/types/controller";
+
+import { KurtosisFormInputProps } from "./types";
+
+type CodeEditorInputProps<DataModel extends object> = KurtosisFormInputProps<DataModel> & {
+  fileName: string;
+};
+
+export const CodeEditorInput = <DataModel extends object>(props: CodeEditorInputProps<DataModel>) => {
+  return (
+    <Controller
+      render={({ field }) => <CodeEditorInputImpl field={field} fileName={props.fileName} />}
+      name={props.name}
+      defaultValue={"" as any}
+      rules={{
+        required: props.isRequired,
+        validate: props.validate,
+      }}
+      disabled={props.disabled}
+    />
+  );
+};
+
+type CodeEditorImplProps<
+  TFieldValues extends FieldValues = FieldValues,
+  TName extends FieldPath<TFieldValues> = FieldPath<TFieldValues>,
+> = {
+  field: ControllerRenderProps<TFieldValues, TName>;
+  fileName: string;
+};
+
+const CodeEditorInputImpl = <
+  TFieldValues extends FieldValues = FieldValues,
+  TName extends FieldPath<TFieldValues> = FieldPath<TFieldValues>,
+>({
+  field,
+  fileName,
+}: CodeEditorImplProps<TFieldValues, TName>) => {
+  return <CodeEditor text={field.value} onTextChange={field.onChange} fileName={fileName} />;
+};

enclave-manager/web/packages/app/src/emui/enclaves/components/form/ListArgumentInput.tsx

@@ -1,14 +1,14 @@
 import { Button, ButtonGroup, Flex, useToast } from "@chakra-ui/react";
 
 import { CopyButton, PasteButton, stringifyError } from "kurtosis-ui-components";
-import { ReactElement } from "react";
+import { FC } from "react";
 import { useFieldArray, useFormContext } from "react-hook-form";
 import { FiDelete, FiPlus } from "react-icons/fi";
 import { KurtosisSubtypeFormControl } from "./KurtosisFormControl";
 import { KurtosisFormInputProps } from "./types";
 
 type ListArgumentInputProps<DataModel extends object> = KurtosisFormInputProps<DataModel> & {
-  FieldComponent: (props: KurtosisFormInputProps<DataModel>) => ReactElement;
+  FieldComponent: FC<KurtosisFormInputProps<DataModel>>;
   createNewValue: () => object;
 };