When one has a lot of resources, the sidebar is noisy and also might require scrolling to see that a resource is unhealthy. Local resources enable use cases that lead to many more resources in the sidebar.

Some spitballing:

• Hide all healthy resources under a "healthy resources" group.
• would probably need some extra control like a "pin" button or tiltfile directive for resources you want to see all the time
• Allow users to define resource groups that can be collapsed/expanded in the sidebar

All Tilt image builds (docker_build and custom_build) use content-based immutable tags. In other words,

• Tilt builds the image
• Tilt checks the contents of the image to compute a digest
• Tilt injects the digest into the kubernetes yaml. Kubernetes is smart enough not to redeploy the image if the digest hasn't changed.

For details on this, see: https://docs.tilt.dev/custom_build.html#why-tilt-uses-immutable-tags

There are two ways this can fall down.

The first is that if the custom_build builds remotely, Tilt doesn't have any way to compute the digest of the output image. This only affects builds that use custom_build(skips_local_docker=True)

The second way is if the custom_build has its own caching mechanism, not based on content hashing. For example if it wants to tag the deployment in some way, and always reconnect to the deployment if the tag matches what it expects.

I can think of a few different options to fix this, based on what stage we want to do the caching:

1. Compute a digest of inputs, as suggested here: https://github.com/tilt-dev/tilt/issues/3690. This puts all the implementation on the Tilt side, but weird things might happen if the user has specified deps wrong.

2. Provide a way for custom_build to specify the digest of the output image. Then Tilt could compare the digest with what's currently deployed, and skip deployment if the digest hasn't changed.

3. Provide a way for custom_build to do its own caching check. i.e., tilt passes in the existing digest/deployment, and the custom_build says "yes, i want to reuse that one!" This might run either pre-image-build or post-image-build

Note that these options aren't redundant - it would be reasonable to implement all of them. (3) is probably the biggest footgun -- a buggy user script could really corrupt your dev environment in weird and difficult-to-diagnose ways. The exact semantics and API might be hard to get right - i'm not totally sure if pre-image-build or post-image-build is right. (2) is probably the safest, but I think it would be hard for users to implement well -- it would be more as a building block for other remote builders.

When using custom_build(..., tag=MYTAG), the image is tagged locally with :MYTAG but the image pushed to the kubernetes cluster has a different tag based on the beginning of the image id, for example :tilt-6838c54d01f71b92. This makes the tag feature less useful for people who need to know what will be the name of the image in the cluster.

If the user uses live_update and set sync()'s local_path to only a subset of the files being set to watch by docker_build() (docker_build()'s context seems to be used to determine which files are being watched), then full builds will be re-triggered for any change in the files not included in sync().

This behaviour is counter-intuitive especially due to the presence of fall_back_on(). I expect that no full rebuild will be triggered unless a path is specified in fall_back_on().

Another way to look at it is through the following use case: At the moment, if the user wants to only trigger a fast-sync on a single file and not having any full rebuild triggered in case any other file changes, it seems necessary to add a sync() encompassing all possible files that might change.

There are two use case we've seen that could be solved by Tilt "lifecycle hooks", or bits of code that only run on tilt up or only run on tilt down.

One is someone who has a problem where they use Helm to disable resources that they aren’t using (so they still build the image, and Tilt complains in to the void that there’s an image that’s not used in any resource) but Tilt never removes the resource from their cluster so it’s still sitting there taking up resources.

Another is that they also have a command in their Tiltfile that tells Helm to deploy persistent resources which are required by our core application, but not managed by Tilt. But what's annoying is that the helm upgrade command also runs on a Tilt down. It doesn't cause functionality problems, since Helm does some checks and decides to do nothing, but it adds time and is unnecessary.

It also might be desirable to have Tilt automatically run the code in the down hook whenever Tilt is exited.

Hi all, I follow this example https://docs.tilt.dev/example_csharp.html and use local resource

This is the project structure:

Working dir

.
├── devops
│   ├── k8s
│   │	  ├── Tiltfile2
│   │	  └── out
├── project1
│   ├── bin
│   ├── obj
│   └── ...
├── project2
│   ├── bin
│   ├── obj
│   └── ...
├── ...
├── Tiltfile1
├── .dockerignore
└── ...

This is the value of my Tiltfile2:

local_resource(
    'publish_local_svc_order_api',
    'dotnet publish ... -c Release -o out',
    deps=[
        '../../../'
        ],
    ignore=[
        './../../**/obj',
        '../../../**/bin'
    ]
)

This is the value of my Tiltfile1:

local_resource(
    'publish_local_svc_order_api',
    'dotnet publish ... -c Release -o out',
    deps=[
        '.'
        ],
    ignore=[
        '**/obj',
        '**/bin'
    ]
)

However, when the local build is running the file in **/bin and **/obj is changed and causing the local_resource run into a loop.

So my questions are:

1. Does ignore support glob pattern? or is this a bug?

2. I know .dockerignore doesn't allow ignore with pattern coming from a child folder ( './../../**/obj' ) but can Titl.dev support this? It will very helpful if I can put the Tiltfile inside a child folder (for organization purpose).

3. Or do we have the feature to set the "working dir/context" of Tiltfile execution instead of always where the Tiltfile is located.

Thanks, DatXN.

Expected Behavior

Port forwarding should work smoothly in windows machines

Current Behavior

• Getting the following error when we updated tilt to v0.29 on windows 10 machines. This doesn't happen on our Mac's:

Reconnecting... Error port-forwarding...(30080 -> 8080): Unable to listen on port 30080: Listeners failed to create with the following errors: [unable to create listener: Error listen tcp6 [::1]:30080: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.]

• Potentially related to this ticket 🤔

Steps to Reproduce

• upgraded to tilt v0.29
• updated k8s_resources in tiltfile to allow it to handle port forwarding (k8s_resource(workload='web', port_forwards=['30080:8080'], labels='Front-end')

Context

tilt doctor Output

Tilt: v0.29.0, built 2022-05-06
System: windows-amd64
---
Docker
- Host: npipe:////./pipe/docker_engine
- Server Version: 20.10.14
- API Version: 1.41
- Builder: 2
- Compose Version: v2.4.1
---
Kubernetes
- Env: docker-desktop
- Context: docker-desktop
- Cluster Name: docker-desktop
- Namespace: default
- Container Runtime: docker
- Version: v1.22.5
- Cluster Local Registry: none

About Your Use Case

• Our frontend service starts failing to connect to BE and throws network errors; would like to have no failures when using our web service and no issues with port forwarding when on a windows machine
• Are there any extra setup steps for windows users to get this sorted out?

Having issues with live_update rebuilding instead of syncing a file change; I've read the relevant docs a few times and can't figure out what I'm doing wrong.

I change the file services/webapp/foo/bar.py and expect a live update, but instead there's a full docker rebuild.

1 File Changed: [/Users/mdb/src/REPO/services/webapp/foo/bar.py] • q-django-core-chart
Will not perform Live Update because:
	Found file(s) not matching any sync (files: /Users/mdb/src/REPO/services/webapp/foo/bar.py)
Falling back to a full image build + deploy

Tiltfile location: /Users/mdb/src/REPO/Tiltfile

Tiltfile snippet:

docker_build(
  'django-core',
  'services/webapp',
  dockerfile='services/webapp/Dockerfile',
  live_update=[
    fall_back_on(['services/webapp/run.sh','services/webapp/django_services/settings.py']),
    sync('./services/webapp', '/src/'),
  ])

My understanding is that the docker_build context path is relative to the Tiltfile directory, and the first argument to 'sync' is also relative to the Tiltfile directory.

I tried modifying the docker build context to also be at the root of the repository, instead of 'services/webapp', but then nothing would happen if I changed the same file (services/webapp/foo/bar.py). I've tried a few other path permutations but haven't gotten anything to work.

Tilt doctor:

Tilt: v0.15.1, built 2020-06-24
System: darwin-amd64
---
Docker (cluster)
- Host: tcp://192.168.64.14:2376
- Version: 1.40
- Builder: 2
---
Docker (local)
- Host: [default]
- Version: 1.40
- Builder: 2
---
Kubernetes
- Env: minikube
- Context: minikube-dev-mdb-Madelaines-MBP.localdomain
- Cluster Name: minikube-dev-mdb-Madelaines-MBP.localdomain
- Namespace: default
- Container Runtime: docker
- Version: v1.18.3
- Cluster Local Registry: none
---
Thanks for seeing the Tilt Doctor!
Please send the info above when filing bug reports. 💗
The info below helps us understand how you're using Tilt so we can improve,
but is not required to ask for help.
---
Analytics Settings
- User Mode: opt-in
- Machine: d98b64728a82a66c0ac94b7062ecbc2d
- Repo: BIU2Fsug9j4BXswD0uPV1g==

Any tips?

Hi,

I saw the FAQ about the issue I encounter today about trying to push to a registry on a local cluster.

Everything was working fine with minikube locally until I changed the name of the project used by minikube to allow me to have two distinct clusters for dev purpose. Launching minikube with minikube -p anothercluster let tilt considers this as a remote cluster instead of local one.

As I watch the source code I saw that we have few cases to find out if it's a local or a remote cluster.

Would it be possible to provide a command to tilt to manually specify a local cluster based on the name of the context?

This will solve my issue and allow user to run the local kubernetes cluster where and which the tool they want (maybe k3os on virtualbox or kvm).

Suggestions:

• tilt set localenv my-context ==> Set a specific k8s context to be a local one (ignoring push)
• tilt get localenv/tilt ls localenv => Get/List localenv

or in another way:

• tilt local set my-context
• tilt local ps/ tilt local get/ tilt local ls

Pick the ones you find the best ;)

Some people want files changed on the container to be copied back to their local filesystem; e.g. running yarn update on container and copying back the updated yarn.lock file so it can be git commit'd).

E.g. Docker Compose supports this behavior via volumes: changes made to the directory on the container get propagated back to the directory locally, and vice versa.

Following the steps at https://docs.tilt.dev/docker_compose.html which essentially boils down to:

git clone [email protected]:windmilleng/express-redis-docker.git
cd express-redis-docker/
tilt up

The docker build of tilt.dev/express-redis-app never seems to happen and log is stuck with the following forever:

──┤ Building: app ├──────────────────────────────────────────────                                         
STEP 1/1 — Building Dockerfile: [tilt.dev/express-redis-app]                                              
Building Dockerfile:                                                                                      
  FROM node:9-alpine                                                                                      
  WORKDIR /var/www/app                                                                                    
  ADD package.json .                                                                                      
  RUN npm install                                                                                         
  ADD . .                                                                                                 
  ENTRYPOINT node server.js                                                                               
                                                                                                          
                                                                                                          
                                                                                                          
  │ Tarring context…                                                                                      
    ╎ Created tarball (size: 9.7 kB)                                                                      
  │ Building image      

Bumps github.com/containerd/containerd from 1.6.6 to 1.6.12.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe the Feature You Want

We would like to attach the snapshots as part of issues, and it would be great if they were as small as possible. It's not like the snapshots have any value without the "viewer", since, although plain json files, they are not natively "viewable"

Current Behavior

Well, now, a 1MB json file is compressed down to 70k and although we could manually compress it and then download and decompress, it would be much more efficient if the viewer was working directly with the compressed format.

Why Do You Want This?

Already described above!

Thanks!

Expected Behavior

No errors in logs

Current Behavior

Many error messages in logs when a custom extension is registered, but never loaded.

ERROR: [] "msg"="Reconciler error" "error"="Failed to update API server: [create extensionrepos/default: extensionrepos.tilt.dev \"default\" already exists, create extensions/helm_resource: extensions.tilt.dev \"helm_resource\" already exists]" "controller"="tiltfile" "controllerGroup"="tilt.dev" "controllerKind"="Tiltfile" "Tiltfile"={"name":"my_ext_2"} "namespace"="" "name"="my_ext_2" "reconcileID"="96266349-e12c-443f-ac40-93f8c8645e54"

Steps to Reproduce

Reproduction at:

https://github.com/markdingram/tilt-extension-test

Context

tilt doctor Output

Tilt: v0.30.13, built 2022-12-01 System: darwin-amd64

About Your Use Case

We have a number of custom extensions. Some of which build on existing extensions like 'helm_resource'. These error messages start spamming the logs if such an extension is registered without being loaded.

Encountered this when creating a single helper function that would handle all the registrations for various Tiltfile's to import. The workaround is to "load_dynamic" all of the extensions as they are registered.

Tilt's docker_build currently attaches builtby=tilt to images. This is used for image pruning.

The OCI spec recommends that all labels should be namespace by the organization that owns them. Ref: https://github.com/opencontainers/image-spec/blob/main/annotations.md

We should change this to some sort of tilt label (dev.tilt.*)

Related: https://github.com/tilt-dev/tilt/issues/4023

Expected Behavior

Runtime logs are seen

Current Behavior

Runtime logs are sometimes not seen after long time of running tilt (10s of hours)

Steps to Reproduce

1. Have docker-compose file, no kubernetes
2. Have the docker_build directive
3. Change some code
4. Watch build logs finish successfully
5. No runtime logs are seen in the tilt console, but they are seen with docker logs -n10docker ps | grep container_name | cut -d" " -f1`

Context

tilt doctor Output

$ tilt doctor
Tilt: v0.30.13, built 2022-12-01
System: darwin-arm64
---
Docker
- Host: unix:///var/run/docker.sock
- Server Version: 20.10.20
- API Version: 1.41
- Builder: 2
- Compose Version: v2.12.1
---
Kubernetes
- Env: unknown
- Context: removed manually
- Cluster Name: removed manually
- Namespace: default
- Container Runtime: docker
- Version: v1.21.14-eks-fb459a0
- Cluster Local Registry: none
---
Thanks for seeing the Tilt Doctor!
Please send the info above when filing bug reports. 💗

The info below helps us understand how you're using Tilt so we can improve,
but is not required to ask for help.
---
Analytics Settings
--> (These results reflect your personal opt in/out status and may be overridden by an `analytics_settings` call in your Tiltfile)
- User Mode: opt-out
- Machine: c5fb1592e4eab9c0bd2124b58977e568
- Repo: tb987Z6kvKu+U4t+WzVbyw==

When you open tilt in a normal terminal, you get a prompt:

(space) to open the browser
(s) to stream logs (--stream=true)
(t) to open legacy terminal mode (--legacy=true)
(ctrl-c) to exit

When you open tilt in a git bash shell, you get a streaming log.

That's because git bash isn't a normal terminal, and doesn't process input in the same way. We would have to write special handling in tilt to make the input prompt support git bash.