DOCSEARCHbyAlgolia
Submit Docs

Tilt Extensions

repository·master·Indexed 42 days ago

https://github.com/tilt-dev/tilt-extensions

A collection of official, vetted extensions for the Tilt development workflow. Includes tools for Kubernetes management (ConfigMaps, deployments, jobs, cert-manager, CoreOS Prometheus), build tool integrations like Conftest, and UI enhancements such as ANSI color logging and process cancellation.

Tokens
33.2K
Snippets
127
Records
180
Agent score
53%

What's inside Tilt Extensions

  1. Overview of the Git Resource extension

    master
    The git_resource extension allows you to deploy a Dockerfile from a remote Git repository or specify a path to a local Git checkout for local development. This is useful for pulling containerized resources from external sources or working with local clones of repositories during development.

  2. Overview of Tilt Extensions

    master
    Tilt Extensions is a collection of vetted and approved extensions for Tilt. These extensions provide additional functionality to your Tiltfile, such as specialized build tools, Kubernetes resource management, and UI enhancements. You can use these extensions to extend Tilt's capabilities for your specific development workflow.

  3. Use the Pulumi extension to deploy services

    master

    The Pulumi extension allows you to use Pulumi to deploy services to a cluster while integrating with Tilt's development loop. It enables features like automatic redeployments based on file changes and Live Update for containers.

    def pulumi_resource(
    name,
    stack='',
    dir='',
    deps=[],
    image_deps=None,
    image_configs=None,
    image_selector='',
    container_selector='',
    live_update=None,
    resource_deps=None,
    labels=None,
    port_forwards=[]):
  ...

  4. Use Earthly to build images for Tilt

    master

    The Earthly extension allows you to use Earthly to build container images within your Tilt workflow. It provides two primary functions: earthly_build for standard image builds and earthly_build_with_restart for builds that support container restarts or live updates.

    load('ext://earthly', 'earthly_build')

earthly_build(
    context='.',
    target='+hello',
    ref='helloimage',
    image_arg='IMAGE_NAME',
    ignore='./test.sh',
    extra_flags=['--strict'],
    extra_args=['--PORT=8000'])
)

  5. Use Podman to build images for Tilt

    master

    The Podman extension allows you to use Podman instead of Docker to build images for your Tilt workflows. It provides two primary functions: podman_build for standard image building and podman_build_with_restart for builds that require a specific entrypoint and support for Tilt's live update capabilities.

    load('ext://podman', 'podman_build')
podman_build('hello-world-image', '.')

  6. Use kim to build images in Kubernetes

    master

    The kim extension allows you to build container images directly within your Kubernetes cluster using kim.

    ⚠️ DEPRECATION NOTICE: This extension is deprecated.

    • If you are using the containerd runtime (default in Rancher Desktop), switch to the nerdctl_build extension.
    • If you are using the dockerd (moby) runtime, use Tilt's built-in docker_build function.

  7. Use the get_obj extension to develop against existing Kubernetes resources

    master

    The get_obj extension allows you to extract the YAML configuration and container image information from an existing Kubernetes resource (like a deployment or statefulset). This is useful for developing, live-updating, and debugging applications that were originally deployed to a cluster via CI/CD or other external tools, rather than managing the full deployment lifecycle within Tilt.

    load('ext://get_obj', 'get_obj')

obj = get_obj(
  name='example-nodejs',
  kind='deployment',
  container_selector='my-container',
  disable_probes=True
)

  8. Use the list_dependencies extension

    master

    The list_dependencies extension provides a UI button on the (Tiltfile) resource in the Tilt dashboard. When clicked, it displays a list of resources currently blocked by dependencies and identifies exactly which dependencies they are waiting for.

    Sample Output Formats:

    When resources are blocked:

    ---- Resources waiting for dependencies ----
Resource 'b' is blocking on 'a'.
Resource 'c' is blocking on 'a' and 'b'.
Resource 'd' is blocking on 'c'.
--------------------------------------------

    When no resources are blocked:

    ---- Resources waiting for dependencies ----
No resources blocked at the moment.
--------------------------------------------

  9. Unsupported cases for the Restart Process extension

    master

    The restart_process extension does NOT support the following:

    • Specific custom_build parameters: Images built using skips_local_docker, disable_push, or tag.
    • Docker Compose: Use the built-in restart_container() instead.
    • Shell-less images: Images built from scratch or distroless (because the extension requires a shell/wrapper environment).
    • Kubernetes command overrides:
      • If the command is specified in a Kubernetes YAML that is known during Tiltfile execution, the extension will override it (but args remain available).
      • If the command is specified in a ContainerSpec via k8s_custom_deploy or similar, the extension will not work.
    • CRDs

  10. How to implement a custom deployment callback

    master

    To generate custom Kubernetes YAML instead of the default generic definition, provide a deployment_callback function.

    Callback Signature: deployment_callback(resource_name, image_name, namespace) -> str

    • resource_name: The name of the resource.
    • image_name: The name of the image (this is the value returned by your build_callback if one was used).
    • namespace: The target namespace.

    Return Value: The callback must return a string or blob containing the Kubernetes YAML definition.

    def my_microservice_deployment_generator(resource_name, image_name, namespace) -> str:
    return f"""
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {resource_name}
  namespace: {namespace}
spec:
  template:
    spec:
      containers:
      - name: {resource_name}
        image: {image_name}
"""

git_resource('myMicroservice', 'git@example.com/myRepo.git', deployment_callback=my_microservice_deployment_generator)

  11. How Syncback implements file synchronization

    master

    The Syncback extension uses rsync rather than kubectl cp for several reasons:

    • Efficiency: It only moves the portions of files that have changed, minimizing data transfer.
    • Completeness: It correctly handles file deletions and renames, which kubectl cp does not.

    To bridge the gap between rsync and Kubernetes, the extension uses a script (krsync.sh) that copies a pre-built rsync binary onto the target container to facilitate the synchronization process.

  12. Use the Hasura console as a side-car

    master

    You can run the Hasura console independently of the main hasura() deployment. This is useful if you want to start the console at a different time or connect it to an external Hasura instance not managed by the current Tilt configuration.

    The hasura_console() command checks if a local project exists at the provided path. If not, it initiates one and loads existing metadata from the Hasura server.