-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to dynamically ignore files at runtime. #3404
Comments
Hey @kogi, Thanks for opening this. I think that makes a lot of sense. This could be pretty easily hacked together by making a Tiltfile function that appends patterns as strings to the in-memory version of the |
fwiw, this has bitten me a lot too |
Any updates/plans/roadmap for this, yet? |
not yet! though there are some changes underway to change the internal data model for the ignores, to make it easier to make/debug changes like this |
❤️ |
A few functions accept an
ignore=[]
flag to prevent triggers on certain files, but most functions don't. In many cases, these ignores can be achieved with the.tiltignore
file, but in some cases, these filenames aren't known until runtime.We have the ability to dynamically watch files with
watch_file()
, but there is no counterpartignore_file()
orunwatch_file()
. Adding this method would allow run-time ignore rules.This may even be a potential solution for #1930 and #2602
In my particular case, I'm using
local('helm pull ...')
andk8s_yaml(helm('path/to/pulled/chart'))
. To ensure we always have a fresh copy of said chart, I'm also doing alocal('rm -rf path/to/pulled/chart')
immediately before the pull. If tilt is already running, then that chart is being watched. If I update my tiltfile, it gets re-run, which deletes that directory, which triggers a re-run, which successfully pulls the chart, and the newly created files, in turn, trigger another re-run, which again deletes the dir, ad nauseum.See tilt-dev/tilt-extensions#19
Since
helm()
doesn't have anignore=[]
flag, there seems to be no way around this. The ability to dynamically un-watch this directory prior to deleting it would solve the problem.The text was updated successfully, but these errors were encountered: