Tilt

If you want to run the Tilt integration tests against a single-use, isolated Kubernetes cluster instead of your existing cluster, you can use kind. This is the method used in CircleCI to ensure a clean environment.

Run the following command to create a kind cluster and execute the tests:

make integration-kind

You can install the tilt binary using a PowerShell command.

iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.ps1'))

You can install the tilt binary using a one-step shell script via curl.

curl -fsSL https://raw.githubusercontent.com/tilt-dev/tilt/master/scripts/install.sh | bash

Tilt integration tests run the Tilt binary to ensure services are correctly deployed. These tests require kubectl to be configured to communicate with an existing Kubernetes cluster. The framework compiles the Tilt binary and deploys servers to the tilt-integration namespace.

Note: The tilt-integration namespace is not deleted automatically after the tests complete.

To run the tests against your existing cluster, use one of the following commands:

go test -tags 'integration' -timeout 30m ./integration

make integration

These tests are excluded from the standard make test command.

Tiltfiles are written in Starlark, a Python-inspired language. This allows you to use standard programming constructs like functions, conditionals, and loops. For large projects, you can organize logic by loading other Tiltfiles.

• Use load_dynamic(path) to load a Tiltfile at a specific path.
• Use watch_file(path) to ensure Tilt re-evaluates when that file changes.
• Use os.path.exists(path) to check for file existence.

For more details on organizing logic, see https://docs.tilt.dev/tiltfile_concepts.html and https://docs.tilt.dev/multiple_repos.html.

def tilt_demo():
    if os.path.exists('tilt-avatars/Tiltfile'):
        load_dynamic('tilt-avatars/Tiltfile')
    watch_file('tilt-avatars/Tiltfile')
    git_checkout('https://github.com/tilt-dev/tilt-avatars.git', 
                 checkout_dir='tilt-avatars')

You can define a ReadinessProbe for a command to ensure it is considered 'Ready' only after a specific check passes. The probe supports two types of handlers:

1. Exec Action: Runs a command within the environment. The command's exit code determines success (0) or failure (non-zero).
2. HTTP Get Action: Performs an HTTP GET request to a specified port. A successful response indicates readiness.

If a probe configuration is invalid (e.g., a port number out of range), the command will fail to start and report a termination error.

localTarget.ReadinessProbe = &v1alpha1.Probe{
    TimeoutSeconds: 5,
    Handler: v1alpha1.Handler{
        Exec: &v1alpha1.ExecAction{Command: []string{"sleep", "15"}},
    },
}

When using an Execer, the statusAndMetadata struct is sent through the status channel to communicate the state of a command. Key fields include:

• status: The current state (e.g., Running, Done, Error).
• pid: The process ID of the running command.
• exitCode: The exit code returned by the process (0 for success, non-zero for errors).
• reason: A string describing why the process stopped (e.g., "killed", or an error message).

The Tilt CLI is organized into several subcommands that control different aspects of the development lifecycle. Based on the internal dependency wiring, the primary subcommands include:

• up: Starts the Tilt development loop, watching for changes and deploying resources.
• down: Stops the Tilt development loop and cleans up resources.
• ci: Runs Tilt in a Continuous Integration mode (optimized for non-interactive environments).
• updog: A specialized mode (likely for specific resource monitoring or interactive debugging).
• tiltfile: Commands related to evaluating or interacting with the Tiltfile.
• docker-prune: Commands for cleaning up Docker resources.
• lsp: Language Server Protocol support for Tiltfiles.

Note: For a full list of available commands and their specific flags, run tilt --help in your terminal.