The git_resource extension's git_checkout has been broken for valid Git repository URLs in the latest version (2d72dab), which added support for specifying git revisions (#134). It incorrectly parses URLs starting with a scheme (i.e. http://, ssh://, ftp://) and that specify a <user>@, which is a completely valid repository URL.

For example, previous versions of the extension would parse perfectly fine the following repository URLs:

git_checkout('https://[email protected]/path/repo.git', 'dest_path')
git_checkout('ssh://[email protected]:54321/path/repo.git', 'dest_path')

However, #134 changed _parse_repository_url() (2d72dab#diff-376d4b8dbfc3fc881c2bc14cef747dd7fdd4903926755b1a924c55d571ead355R105-R113) so that it incorrectly splits at the @ and gives an error like the following when attempting to clone a URL such as https://[email protected]/path/repo.git:

local: basename https://user .git
local: git clone https://user --recurse-submodules --shallow-submodules dest_path && cd dest_path && git checkout example.com/path/repo.git
Successfully loaded Tiltfile (5.325367799s)
Traceback (most recent call last):
  /some/path/to/Tiltfile:113:4: in <toplevel>
  /some/path/to/Tiltfile:75:15: in all
  /some/path/to/tilt_modules/git_resource/Tiltfile:57:22: in git_checkout
  <builtin>: in local
Error: command ["sh" "-c" "git clone https://user --recurse-submodules --shallow-submodules dest_path && cd dest_path && git checkout example.com/path/repo.git"] failed.
error: exit status 128

Notice above how it tries to git clone https://user.

Currently, if you run tilt in an SSH session, the kubefwd extension will fail with this error:

Error executing command as another user: No authentication agent found.

The problem is that

1. kubefwd needs sudo access
2. the kubefwd extension asks for sudo access with pkexec
3. pkexec can't call out to a GUI sudo, so fails

I'm not sure what the right solution for this is. Here's a few ideas I tossed around:

Could we multiplex the TTYs so that we could gracefully handle it when one asks for sudo access? I don't think the underlying OS APIs offer a reasonable way to do this though.

I considered adding an option to expose the tty as a web app in the tilt UI (as in https://github.com/yudai/gotty). But I think there are security concerns with that.

Could we add a tilt attach command, like kubectl attach or docker attach to attach a TTY to an existing session when you need to input a password? This is probably the most common solution in this space.

What if we told people that you should make your sudo password a Secret (either in kubernetes, or in the tilt apiserver)? Then kubefwd could read that secret when it needs to. But I'm a bit worried this just kicks the can somewhere else without resolving the problem (when/how to notify the user when a program is requesting elevated privileges).

A great trend was started with #9 including a README.md since then many plugins have also adopted this. I think it's not only a great way for future users to see it but it makes reviewing the methods/usage much easier than just looking at the raw code.

We should obviously update the contributing guide.

It would be epic if we also added a CI step that validated that the readme existed in all folders to give a helpful hint.

What are your thoughts?

output:

...
local: tar -C /var/folders/f8/pqx_d6kx5hgdvghjhhf0qd8h0000gn/T/tmp.lBoYMb6e/prometheus-operator-kube-prometheus-v0.5.0 -xzf /Users/user/code/repos/flare/tilt_modules/coreos_prometheus/.tilt-cache/coreos-kube-prometheus-v0.5.0.tar.gz --strip-components=1 --wildcards 'prometheus-operator-kube-prometheus-*/manifests'
 → tar: Option --wildcards is not supported
 → Usage:
 →   List:    tar -tf <archive-filename>
 →   Extract: tar -xf <archive-filename>
 →   Create:  tar -cf <archive-filename> [filenames...]
 →   Help:    tar --help
Successfully loaded Tiltfile (4.120123106s)
Traceback (most recent call last):
  /Users/user/code/repos/flare/Tiltfile:15:1: in <toplevel>
  /Users/user/code/repos/flare/tilt_modules/coreos_prometheus/Tiltfile:176:25: in <toplevel>
  /Users/user/code/repos/flare/tilt_modules/coreos_prometheus/Tiltfile:66:10: in download_files
  <builtin>: in local
Error: command ["sh" "-c" "tar -C /var/folders/f8/pqx_d6kx5hgdvghjhhf0qd8h0000gn/T/tmp.lBoYMb6e/prometheus-operator-kube-prometheus-v0.5.0 -xzf /Users/user/code/repos/flare/tilt_modules/coreos_prometheus/.tilt-cache/coreos-kube-prometheus-v0.5.0.tar.gz --strip-components=1 --wildcards 'prometheus-operator-kube-prometheus-*/manifests'"] failed.
error: exit status 1

I haven't traced down the source of this tar usage yet to look at a patch but the issue looks as simple as usage of the non-portable --wildcards flag which won't work on macOS; perhaps an alternative syntax could be used here (but not sure what other issues might follow).

Both tilt-restart-wrapper and entr are only compiled for amd64, so will result in exec errors if used for an ARM container (e.g. pushing to a k3s cluster on a Raspberry Pi).

We should either publish multi-arch images for tiltdev/restart-helper or update documentation to note that this is only supported for amd64 targets.

Say I have some tests I want to run inside a container in my cluster.

If I don't use a deployment for the container (e.g., use a Job), then I can't live update and end up doing extra image builds + deploys.
If I do use a deployment, then I can live update, but I don't have a way to indicate failure in the UI.

Some potential Tilt features that could improve this situation:

• a way for the process in the container to log something that the UI indicates as a warning or failure
• a way to specify that resource B should be built after resource A builds. In this case, we could define one resource to run the pod and another resource to kubectl exec the tests inside the pod. When a file changes, it would get live-updated to the pod and then trigger the kubectl exec resource.

This is also just kind of a special case of the "how do I use live_update with a Job?" question.

If you have cmd_button('foo', resource='bar', cmd=['echo', 'hi']) and either remove it from Tiltfile or change the button ID (foo -> foo2), the old button will not be removed.

The workaround for now is to restart Tilt as buttons are not persistent across tilt up runs.

I wanted to contribute more tilt extensions to this project but i have a question in mind. Is it okay to include existing tilt extensions in other extensions? For example, i want to use local_output extension in my further contributions. Is it possible or should i inline it?

Love the UI button extension! I would like to make a button that toggles certain config parameters. For example:

load('ext://uibutton', 'cmd_button', 'location')

config.define_bool('cache')
cfg = config.parse()
cache = cfg.get('cache',False)

button_icon = 'sync_disabled' if cache else 'sync'
button_text = 'turn caching off' if cache else 'turn caching on'

cmd_button(name='caching-toggle-button',
        argv=["tilt","args","--","--cache="+("false" if cache else "true" ],
        text=button_text,
        location=location.NAV,
        icon_name=button_icon)

local_resource("blah", "echo hello world")

However, this causes infinite cycling. It appears that when the cmd_button click runstilt args -- --cache=true, the refreshing tiltfile executes the argv immediately again rather than waiting for the next click thereby starting a cycle. Another way to say this is, cmd_button runs the argv command on load rather than on click when tilt args -- --cache=true is the source of the tiltfile refresh AND when the UI button has been clicked at least once.

With an even simpler test Tiltfile:

load('ext://uibutton', 'cmd_button', 'location')

config.define_bool('cache')
cfg = config.parse()

cmd_button(name='caching-toggle-button',
        argv=["echo", "blah"],
        text='sync',
        location=location.NAV,
        icon_name='sync')

local_resource("blah", "echo food")

Steps to reproduce:

1. tilt up
2. open another terminal (2) and tilt args -- --cache=false and get expected behavior
3. click button and see echo blah
4. in terminal (2), tilt args -- --cache=false again and get an invocation of echo blah without clicking the button.
5. click the tilt refresh tiltfile button or change a line in the Tiltfile itself and again get an invocation of echo blah even without clicking the UI button.

Something about step 3 creates the on load exec of argv.

(I'm on mac and using tilt 0.21.2)

Upon adding the kubefwd extension using the instructions here I got an error in the kubefwd:config local resource:

Error: Refusing to run 'local' because dev-3 might be a production kube context.
If you're sure you want to continue add:
	allow_k8s_contexts('dev-3')
before this function call in your Tiltfile. Otherwise, switch k8s contexts and restart Tilt.

I had however, already added dev-3 to the list of allowed contexts using allow_k8s_contexts.

When I modified the extension's Tiltfile directly by adding an allow_k8s_contexts call directly before the local command here, however - the extension loaded up and worked just fine.

I was working through Syncback errors with a coworker today and she noticed that this recent commit quotes some arguments in a way that breaks correct argument parsing. After reverting krsync.sh to the version int he last commit, it worked for me again.

You can see here that the last part is quoted, but should not be since it is not actually a single argument but many.
https://github.com/tilt-dev/tilt-extensions/blame/018a67d9a544f9f1df6238074db9e781ef7af60b/syncback/krsync.sh#L18

The syncback extension fails to verify rsync on linux (Manjaro).

I have rsync 3.2.3 installed, but getting this error.

→ Could not parse local rsync version (need version >= 3.0.0)

Tracked the issue down to the rsync version regex not accounting for differences in outputs for rsync --version.

Expects:

rsync  version 3.2.3  protocol version 31

Receives (note the preceding v before 3.2.3):

rsync  version v3.2.3  protocol version 31

Currently, helm_remote calls namespace_create to create a namespace

https://github.com/tilt-dev/tilt-extensions/blob/master/helm_remote/Tiltfile#L62

It's understandable why it does this! Helm 2 also does this. The behavior was extremely controversial, and was removed in Helm 3.

For discussion, see:
https://helm.sh/docs/faq/
helm/helm#5753

It also creates problems where if you try to create two helm charts in the same namespace, tilt will fail (due to the new duplicate yaml check)

I think there are a couple ways we can move forward with this. I think my suggestion is to add a create_namespace flag (similar to Helm3's --create-namespace), but i'm not sure if the default should be True (for backwards-compatibility) or False (to be more forward-looking to what Helm3 does)

What do others think?

cc @maiamcc as exterminator this week
cc @kogi as the author of this extension

The coreos_prometheus extension fails to run on Windows. (a similar issue was raised for Mac, but already fixed -- lucky *nix/mac users...)

Errors: Many. I believe the first error was that the command mktemp could not be found.

This makes sense of course, since the extension was written to use linux commands rather than cross-platform ones. That said, it would be nice if the extension could be made cross-platform.

There are a few different options for cross-platform build scripts:

• Python
• NodeJS
• Linux-command emulator for Windows (shx, shelljs, bash [eg. as installed through Git for Windows], cygwin, etc)

Which of the options above (or others) would the extension maintainers consider acceptable for a PR?

In the meantime, I hacked together a Windows version of the script, by:

1. Converting paths to use \ instead of /, when calling os.path.join and such.
2. Converting all calls to linux-only commands to be wrapped as bash -c "...".
3. A couple other small changes. (eg. changing the if-statement for checking when the root directory has been reached)

With those changes, it worked fine for me.

Here is the gist: https://gist.github.com/Venryx/a1a217e2b56dd037bf0ac164dad6c236

Comments?

Hi all,

I'm trying to setup a dev environment using the Helm template for GoogleCloudPlatform/spark-on-k8s-operator on Tilt.
Unfortunetly something is failing while interpreting the crds.yaml file:

local: helm pull incubator/sparkoperator --untar --destination /home/me/Workspaces/Kubernetes/tilt-spark-operator/.helm/incubator/latest
 → [no output]
local: grep --include '*.yaml' --include '*.yml' -rEil '\bkind\s*:\s+CustomResourceDefinition\s*$' /home/me/Workspaces/Kubernetes/tilt-spark-operator/.helm/incubator/latest/sparkoperator || true
 → /home/me/Workspaces/Kubernetes/tilt-spark-operator/.helm/incubator/latest/sparkoperator/templates/crds.yaml
Successfully loaded Tiltfile (1.60181403s)
Traceback (most recent call last):
  /home/me/Workspaces/Kubernetes/tilt-spark-operator/Tiltfile:2:12: in <toplevel>
  /home/me/Workspaces/Kubernetes/tilt-spark-operator/tilt_modules/helm_remote/Tiltfile:88:17: in helm_remote
  /home/me/Workspaces/Kubernetes/tilt-spark-operator/tilt_modules/helm_remote/Tiltfile:110:17: in install_crds
  <builtin>: in k8s_yaml
Error: json: line 0: invalid character '{' looking for beginning of object key string

The YAML file in question starts like this:

# sparkoperator/templates/crds.yaml
{{ if .Values.installCrds }}
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: (unknown)
  creationTimestamp: null
  name: sparkapplications.sparkoperator.k8s.io
spec:
  group: sparkoperator.k8s.io

I'm guessing that the {{ if .Values.installCrds }} part is causing problems.

The install_crds method in helm_remote seems to have code for handling that, but it only seems to check for {{- and not {{.
When I change the check from {{- to {{ the original error goes away, but a new error for a component uncategorized appears:

STEP 1/1 — Deploying
     Injecting images into Kubernetes YAML
     Applying via kubectl:
     → spark-operator:namespace
     → sparkapplications.sparkoperator.k8s.io:customresourcedefinition
     → scheduledsparkapplications.sparkoperator.k8s.io:customresourcedefinition
     → sparkoperator:serviceaccount
     → sparkoperator-spark:serviceaccount
     → sparkoperator-cr:clusterrole
     → sparkoperator-crb:clusterrolebinding

Build Failed: kubectl apply:
stderr: Error from server (Invalid): error when creating "STDIN": CustomResourceDefinition.apiextensions.k8s.io "sparkapplications.sparkoperator.k8s.io" is invalid: [spec.validation.openAPIV3Schema.properties[spec].properties[driver].properties[sidecars].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property, spec.validation.openAPIV3Schema.properties[spec].properties[driver].properties[initContainers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property, spec.validation.openAPIV3Schema.properties[spec].properties[executor].properties[sidecars].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property, spec.validation.openAPIV3Schema.properties[spec].properties[executor].properties[initContainers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property]
Error from server (Invalid): error when creating "STDIN": CustomResourceDefinition.apiextensions.k8s.io "scheduledsparkapplications.sparkoperator.k8s.io" is invalid: [spec.validation.openAPIV3Schema.properties[spec].properties[template].properties[driver].properties[sidecars].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property, spec.validation.openAPIV3Schema.properties[spec].properties[template].properties[driver].properties[initContainers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property, spec.validation.openAPIV3Schema.properties[spec].properties[template].properties[executor].properties[initContainers].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property, spec.validation.openAPIV3Schema.properties[spec].properties[template].properties[executor].properties[sidecars].items.properties[ports].items.properties[protocol].default: Required value: this property is in x-kubernetes-list-map-keys, so it must have a default or be a required property]
: exit status 1

At this point I'm clueless how to proceed...

Here's a repo for reproducing:
https://github.com/nightscape/tilt-spark-operator/

I'd be thankful for any pointers 😃

In https://github.com/tilt-dev/tilt-extensions/blob/master/kubebuilder/Tiltfile#L15 assumes the defaults used in the kubebuilder initialized Makefile

For cases where the end user needs to add new annotations/options to the controller-gen run command, it would be good to have an option to specify them through the kubebuilder extension.

For instance in my case I need preserveUnknownFields to be set to true

CRD_OPTIONS ?= "crd:trivialVersions=true,preserveUnknownFields=true"

Hello 👋

I'm actually trying to run Linkerd2 with Tilt. I'm trying to use helm for that case by following that : https://linkerd.io/2/tasks/install-helm/. I need to use --set-file option but it's not available with helm_remote.

Maybe I missed something.

My actual workaround is to generate my config.yaml file in Python to inject the files into it.

Thanks

Hello.

i am new to Tilt and am trying it out.

So far my tests worked, but now i wanted to try out an extension. Since a custom button could be really useful i tried that. But unfortunately even copying the example 1:1 it gives me the following error

​Loading Tiltfile at: D:\Projects\testproject\Tiltfile
Traceback (most recent call last):
  D:\Projects\testproject\Tiltfile:37:11: in <toplevel>
  D:\Projects\testproject\tilt_modules\uibutton\Tiltfile:93:27: in cmd_button
  D:\Projects\testproject\tilt_modules\uibutton\Tiltfile:107:19: in _now
  <builtin>: in local
Error: command ["cmd" "/S" "/C" "date -u +\"%Y-%m-%dT%H:%M:%S.000000Z\""] failed.
error: exit status 1
stdout: "Eingegebenes Datum kann nicht \x81bernommen werden.\r\nGeben Sie das neue Datum ein: (TT-MM-JJ) "
stderr: ""

Am i doing anything wrong?

My first guess would be that the cmd_button extension is not really compatible with the german date format?

But then.. why is a button even needing a date?

tilt_modules\helm_remote\Titlefile:121:41: in helm_remote
tilt_modules\helm_remote\Titlefile:63:58: in get_local_repo
Error: string index: got string, want int

When setting up a new machine for the first time, typically the list of local repositories will be empty when calling helm repo list

helm returns an error message rather than an empty array of repos. In this situation it leads to the error above.

The workaround is to add a single remote repository to the helm list and then the system begins working correctly.

helm repo add bitnami https://charts.bitnami.com/bitnami

OS: Windows 10

Introduction

Restart process wrapper returns exit code zero even if software exits with any other. That affects on Tilt UI side so that service seems ok(green) even though it is not. Problem lies on used entr cli command, that seem to be returning its own exit status, instead of the status code from software it runs.

Example

Lets have a script that fails on star

$ cat fail.sh 
#!/usr/bin/env bash

exit 1

And then we run restart process wrapper

$ go run tilt-restart-wrapper.go -entr_path=/usr/bin/entr -watch_file=test.go -- ./fail.sh; echo $?
hi there
0

The last line 0 is exit status of restart process wrapper, and in this case it should be 1 instead of 0.

This can be tracked to be fault(or feature depending on the view) of entr cli tool:

$ echo "./test.go" | entr -rzns ./fail.sh; echo $?
0

Here we have same failing script but the entr is only returns zeroes.

How to almost fix this

One can use Kubernetes liveness properties in case there is multiple component starting up and they depend on eachother, but the most annoying part of this is that Tilt user interface lies about everything being ok even though it is not. We have 15 to 20 components in our software that is started up/developed and if one of them fails, you don't get any indication about it.

Likely fix

My bet would be to get rid of the entr tool, since this is likely feature of the tool. It shouldn't be that hard to make golang code to run application and restart it when some files changes. What do you think? Unfortunately this is way too big of the job for now for me to do pull request since I have schedule of my own.

Because the extension creates a "cmdsfile" and expects to have 1x command per line so it can grab the line index for the corresponding step, newlines in the commands will result in breakage.

To avoid weird splitting/quoting/etc issues, easiest solution is probably to just create step-N.sh wrapper scripts with the contents of the command from the Tiltfile and run those directly.

Hi,

For multistage builds it would be helpful if docker_build_with_restart could target a specific stage similar to the normal docker_build https://docs.tilt.dev/api.html#api.docker_build

Would be nice for git_resource to do a git pull if an update is requested for a resource (hitting the refresh in the UI). So we can pull in changes to upstream dependencies, and include them as part of a fresh build.

Should be optional, via a feature flag.

Hello,

I wonder about the installation of each chart. For each helm_remote, the command makes these instructions:

# ======== Perform Installation
local('rm -rf %s' % pull_target)
local(pull_command)
install_crds(chart, chart_target)

So it will download each time the chart and remove the previous. Moreover, in my case i have a uniq chart for several service (called A, B, C for the exemple)

So, the script makes the following

downloading `myChart` and start it for service 'A'
removing `myChart`
downloading `myChart` and start it for service 'B'
removing `myChart`
downloading `myChart` and start it for service 'C'
removing `myChart`

As you can see, step are very useless because of removing and downloading the same chart.

Good points

• Ensure that charts are always up-to-date

Bad points

• Useless expansive operation (dowloading)
• Useless blocking operation before starting tilt watch (Because all downloads have to be finished before start tilt)

What do you think about that ? :)

To organize our sidebar, we have done the (probably terrible!) thing of adding some empty resources:

local_resource("----Useful Scripts---", "true", trigger_mode=TRIGGER_MODE_MANUAL,
               auto_init=False, serve_cmd="")

Unfortunately, the cancel extension is not happy about them:

reconciling ---Other Services---:update
Error: bad flag syntax: ---Other Services---:update

Every time I cancel or restart a service, I get a new cancel button with it! I have to restart tilt to make it go away.

(I'm super excited to have them, though!)

I think the helm_remote plugin doesn't keep helm resources in order to apply!

I've got some code that I use pretty often when working with nested tiltfiles.

Bit of an edge case, but if you think it's useful feel free to modify it and stick it into the base extensions.

def get_root_directory():
  tilt_root_directory = os.getenv('TILT_ROOT_DIRECTORY')

  if tilt_root_directory == None:
    tilt_root_directory = os.getcwd()
    os.putenv('TILT_ROOT_DIRECTORY', tilt_root_directory)
  
  return tilt_root_directory

Not really sure what the naming conventions are, but I could make a PR if we like it.

Hi,

We have the following use-case:

1. We have a helm chart with a deployment, and in this helm chart, we have defined lots of arguments for Java for example

2. We have a Dockerfile, in this dockerfile, we specify the ENTRYPOINT as
   ENTRYPOINT ["/bin/bash", "-e", "./entrypoint.sh"]

3. This entrypoint.sh script is launching our Java app, with arguments all around (JVM plus App parameters)... and we use the fact that by default, Docker execution passes all extra arguments into the entrypoint without specifying it anywhere

4. Now, with Tilt, this does not seem to work, as kind-of stated in the README here: https://github.com/tilt-dev/tilt-extensions/tree/master/restart_process, however you state here that there is a possibility to use Args... but not documented

5. What happens is that in the end, in docker I see this for example with "kubectl describe"

 containers:
  - args:
    - -Xms1g -Xmx3g
    - -Dspring.config.location=classpath:application.yaml,file:///etc/spring/custom-application.yaml
    - -Dlog4j.configurationFactory=xxx
    - -Dcore.tls.enabled=false
    - -Dcore.application.name=app
    - -Dcore.logtransformer.port=5014
    - com.company.Application
   command:
    - /tilt-restart-wrapper
    - --watch_file=/tmp/.restart-proc
    - sh
    - -c
    - /bin/bash -e ./entrypoint.sh
   env:

and with "docker inspect":

        "Path": "/tilt-restart-wrapper",
        "Args": [
            "--watch_file=/tmp/.restart-proc",
            "sh",
            "-c",
            "/bin/bash -e ./entrypoint.sh",
            "-Xms1g -Xmx3g",
            "-Dspring.config.location=classpath:application.yaml,file:///etc/spring/custom-application.yaml",
            "-Dlog4j.configurationFactory=xxx",
            "-Dcore.tls.enabled=false",
            "-Dcore.application.name=app",
            "-Dcore.logtransformer.port=5014",
            "com.company.Application"
        ],

As you can see, TIlt replaced the command, and it gets "distributed" into path and args... and the extra arguments coming from helm are "appended" at the end... however, in entrypoint.sh, absolutley no arguments are passed in. I do not really know how these values get merged together into a single command line, how they are escaped, quoted etc...

Could you perhaps help us to find a nice way around this issue? Maybe document some of them in the Readme? Preferrably one that does not need to touch the production code that we intend to have. What we were thinking so far:

1. Use some WA from here: https://docs.tilt.dev/live_update_reference.html#workarounds-for-restarting-your-process
2. Instead of Args, use an Env variable ... This is not good for us for several reasons
3. Add a small trick to the TIltfile, to parse the deployment YAML, and extract the args, and set the new entrypoint passing these args explicitly

If the target Docker image that the restart_process extension inherits FROM uses a user other than root then the resulting image will fail to build with the following error message:

Build Failed: ImageBuild: executor failed running [touch /.restart-proc]

Repro case: https://github.com/jazzdan/tilt-restart-process-permissions-error

(note how the Dockerfile here uses the deno user)

Hi there,

I've been attempting to use the file_sync_only extension. It doesn't actually work for me because this line sets up a dependency on a resource using image.

Doesn't this rely on the assumption that the deployment and its image are named the same? What if I replaced the image with my nginx image; paulcwarren/nginx? My tests seem to indicate this will fail.

Or am I mis-understanding something?

I'm quite happy to submit a PR with a fix for this but I wanted to check my understanding before doing so (I am fairly new to Tilt).

Thanks

Kubernetes version being returned from the integrated Kubernetes on my Docker for Mac install is v1.16.6-beta.0, which results in an error when trying to use a Tiltfile that uses the min_k8s_version extension.

Looks to be related to:

I think it would be helpful if kubefwd would run in a docker container.
This would make tilt environment more portable, as it wouldn't require users to manually install kubefwd on their machine.
Also, it would enable kubefwd version pinning per project (not saying it's necessary, but it's always good to know that everyone is using the same version)

git_checkout() is git shallow cloning, which fixed one single branch and thus, can't fetch other new remote branches in an existing repo_dir.
Can we add some arguments to allow developers to do normal git clone or a shallow one?
Thank you.

buttons have the ability to replace lots of local_resources that are used to manually trigger one-off scripts. the drawback to replacing local resources with buttons is that it isn't as easy to see if a script fails or exits with an error code. with a local resource, you can see a pending, healthy, and error status.

maybe this gets into tricky territory if i want buttons to have the same state as resources, but i think it would be helpful to see at least a visual indication in the tilt dashboard that a button command has failed.

(for reference, this feature request came out of my work on !4964.)

cc: @landism @milas

We are using tilt with helm_remote extension to pull helm chart from private registry and things are working as expected. But when a new chart is released in our repo (e.g 0.0.2), and a user updates the version in helm_remote block in the Tiltfile (e.g 0.0.1 > 0.0.2), tilt throws error that it cannot find the chart. Note: this update is done while tilt up is already running.

From what I can tell, it seems this is intended as the helm_remote extension code seems to only do helm repo update when tilt is first brought up?
https://github.com/tilt-dev/tilt-extensions/blob/master/helm_remote/Tiltfile#L17
https://github.com/tilt-dev/tilt-extensions/blob/master/helm_remote/Tiltfile#L131

Is it possible to update the repo when a change in the version is detected? This means in our case the user has to issue helm repo update to workaround. Perhaps there is even a workaround using tilt itself, but it would be great if this was autodetected. Thank you for your efforts.

maybe not the correct solution but something like below?

@@ -161,6 +161,8 @@ def helm_remote(chart, repo_url='', repo_name='', release_name='', values=[], se
 
     if needs_pull:
         # -------- commands
+        repo_command = 'repo update'
+        local(build_helm_command(repo_command), quiet=True)
         pull_command = 'pull %s/%s --untar --destination %s' % (repo_name, chart, pull_target)

git_checkout('[email protected]/my/repo.git#someTagName')

Result:

You are not currently on a branch.
Please specify which branch you want to merge with.

We use some Unix specific commands/tools:

• basename to determine repo name from URL/path (#212)
• wc -l to determine if any files changed from git status output (#216)

See comment in relevant PR: #58 (comment)
The command in helm_remote\Tiltfile:~111 containing || true doesn't work by default on Windows. Changing to || exit 0 appears to work.

If something is dependent on helm_remote, there is no way it can be managed in the regular tilt flow. Any idea how this can be done ?

Looks like helm made a major breaking change in a patch release and there's a lot of fallout right now

https://github.com/helm/helm/releases/tag/v3.3.2
https://github.com/helm/helm/releases/tag/v2.16.11

basically, "helm remote add" now fails if the repo already exists. There are flags to change the default behavior, but they're not in old releases :(

There's already inconsistency in which user Tilt executes run statements as (see tilt-dev/tilt#3708): in --update-mode=container, run statements are exec'd as root; in --update-mode=exec, they're exec'd as the container user.

In another wrinkle, when using the docker/custom_build_with_restart, Tilt will always exec run statements as root, because of this change: #62 (this change switches the user to root before creating the file used to signal process restarts; when trying to create this file as a non-root user (inherited from the parent Dockerfile), Docker would throw a permissions error).

Ideally, docker/custom_build_with_restart would leave the container user unchanged from the value specified in the parent Dockerfile (tho given tilt-dev/tilt#3708 that's of limited use :-/ ).

We are using jfrog artifactory to host our charts, more than 1 chart is hosted on the same repo.
The installed chart not necessarily equal to the repo name, This cause it to fail on checking if it exist and trying to re add the repo.

use case example

helm repo list output:

NAME                    URL                                                                
istio.io                https://storage.googleapis.com/istio-release/releases/1.4.2/charts/
virtual-helm            https://coolguys.jfrog.io/artifactory/virtual-helm     <--- has several charts 

tilt file code:

helm_remote('local-tilt-mongo-dev',
 repo_name="virtual-helm",
 repo_url='https://coolguys.jfrog.io/artifactory/virtual-helm',
 release_name="mongo-dev",
 username=username,
 password=password)

it fails due to this checking only the chart name and not the repo name.

def get_local_repo(repo_name, repo_url):
        # if no repos are present, helm exit code is >0 and stderr output buffered
        added_helm_repos = decode_yaml(local('helm repo list --output yaml 2>/dev/null || true', command_bat='helm repo list --output yaml 2> nul || ver>nul', quiet=True))
        repo = [item for item in added_helm_repos if item['name'] == chart and item['url'] == repo_url] if added_helm_repos != None else []. <--problematic if

The fix #241

repo = [item for item in added_helm_repos if item['name'] == repo_name and item['url'] == repo_url] if added_helm_repos != None else [] 

I recently ran into the issue where the docker_build_with_restart in the restart_process extension doesn't work if the root user doesn't exist in the image that is being used. I saw that in issue #52, the user was hardcoded to be the root user, which makes sense. However, Golang binaries are frequently deployed in scratch containers that don't have a root user. The solution so far has been to just make a second Dockerfile that has FROM alpine instead of FROM scratch. It'd be great not to have to do this though.

Currently, the podman_build extension binds the deps param in the custom_build function to passed the context:

This is not always the case, as most of the times we want to observe just the files needed by the image to trigger a rebuild.
We should add an extra deps param that defaults to the context if not passed.

Currently, the ko extension does a go get $importpath (see ko-build/ko#237) and then calls ko deploy $importpath if you pass a non-relative path, e.g. ko_build('ctlptl', 'github.com/tilt-dev/ctlptl/cmd/ctlptl') if you wanted to build ctlptl from a random different project.

This doesn't really work in a module situation, see ko-build/ko#60 (comment) for more details.

I think in general, for modules, you need to be within the project folder hierarchy (i.e. at or below where go.mod is) or most Go module-aware tooling won't work right.

I've been running into an issue where Tilt is rebuilding on a loop, invoked from helm chart content changes

It is reproducible with the Tiltfile contents being:

load('ext://helm_remote', 'helm_remote')
helm_remote('traefik', repo_url='https://helm.traefik.io/traefik', values=['traefik-helm-values.yaml'])

now create a file called traefik-helm-values.yaml in the same directory (empty file contents, specific values don't matter)

Run tilt up, and it handles it all as expected, now make a change to the traefik-helm-values.yaml (any change, eg. add an #)
Tilt will then be on an indefinite loop with the following output

1 File Changed: [traefik-helm-values.yaml] • (Tiltfile)
... (usual output)

32 Files Changed: [.helm/traefik/latest/traefik .helm/traefik/latest/traefik/.helmignore .helm/traefik/latest/traefik/Chart.yaml .helm/traefik/latest/traefik/Guidelines.md .helm/traefik/latest/traefik/LICENSE ...] • (Tiltfile)
Beginning Tiltfile execution
local: helm repo add traefik https://helm.traefik.io/traefik || helm repo add traefik https://helm.traefik.io/traefik --force-update
 → "traefik" has been added to your repositories
local: rm -rf /home/user/helm-tilt-issue/.helm/traefik/latest/traefik
 → [no output]
local: helm pull traefik/traefik --untar --destination /home/user/helm-tilt-issue/.helm/traefik/latest
 → [no output]
local: grep --include='*.yaml' --include='*.yml' -rEil '\bkind[^\w]+CustomResourceDefinition\s*$' /home/user/helm-tilt-issue/.helm/traefik/latest/traefik || exit 0
 → /home/user/helm-tilt-issue/.helm/traefik/latest/traefik/crds/tlsstores.yaml
 → /home/user/helm-tilt-issue/.helm/traefik/latest/traefik/crds/traefikservices.yaml
 → /home/user/helm-tilt-issue/.helm/traefik/latest/traefik/crds/ingressrouteudp.yaml
 → /home/user/helm-tilt-issue/.helm/traefik/latest/traefik/crds/middlewares.yaml
 → /home/user/helm-tilt-issue/.helm/traefik/latest/traefik/crds/ingressroute.yaml
 → /home/user/helm-tilt-issue/.helm/traefik/latest/traefik/crds/ingressroutetcp.yaml
 → /home/user/helm-tilt-issue/.helm/traefik/latest/traefik/crds/tlsoptions.yaml
Running: [helm template traefik /home/user/helm-tilt-issue/.helm/traefik/latest/traefik --include-crds --namespace default --values traefik-helm-values.yaml]
Auto-detected local registry from environment: {localhost:5000 registry.local:5000 }
Successfully loaded Tiltfile (3.024881843s)

"32 File Changed: " on repeat.

for what it's worth I'm using:

Ubuntu 18.04

Tilt version: v0.18.0, built 2020-12-11
k3d v1.7

cluster + local registry invoked with ./k3d-with-registry.sh --server-arg --no-deploy=traefik

From a really brief and novice investigation it the issue derives from changing the values file results in a complete rebuild via

when it could/should just be a helm upgrade to prevent resource recreation (unless neccessary)

First reported in #tilt in Kubernetes Slack

the namespace_inject function attempts to set a namespace for every template on a kubernetes resource. However, it makes the false assumption that the inner template will always have a metadata key. This is the case for all top-level resources, and also for resources such as Deployment but not for CronJob.

The following code is what's causing problems:

    for k, v in o.items():
      if k == 'template':
        v['metadata']['namespace'] = ns
      if type(v) == 'dict' or type(v) == 'list':
        _set_template_namespace(v, ns)

the function will keep descending recursively into every template. In my case, the offending yaml is this:

# Source: jobs/charts/laravel/templates/scheduler.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: leo-jobs-scheduler
spec:
  schedule: "* * * * *"
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          volumes:
            - configMap:
                name: oauth-public-key
              name: oauth-public
          containers:
            - name: laravel-scheduler
              image: eu.gcr.io/project/image:latest
              command: ["php", "artisan", "schedule:run"]
              volumeMounts:
                - mountPath: /app/storage/oauth-public.key
                  name: oauth-public
                  readOnly: true
                  subPath: oauth-public.key
              envFrom:
                - secretRef:
                    name: leo-jobs-env

Note spec.jobTemplate.spec.template: it is a template key (and thus gets picked up), but doesn't contain a metadata section

A user writes

I have an express app, (nodejs) this app has both front-end static assets and backend js files. I would like to always sync the files but selectively restart only if the backend files changes
Now the issue is that the folder structure is /app/src/views contains the frontend static files, and /app/src/* contains all the js files…

The run() live_update step supports conditional triggers, so it should be possible to only run restart_process conditionally on certain changes, we just need to parameterize docker_build_with_restart for this

https://docs.tilt.dev/api.html#api.run