tilt-dev / tilt-dev/tilt

Ability to un-ignore files

Open
#3,070 1 comment 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
10.1k
Forks
413
Avg merge
1d 10h
Merged PRs (30d)
6

Description

As raised by @djcp in #tilt:

A pretty common dev pattern (in ruby and node) is to use dotenv to set up base ENV, and then use .env.local to establish ENV that includes sensitive data for local development - keys, private URLs, etc. For [production] docker builds yeah, you want to exclude .env.local. But for development, you want that file to be included.
...
even though the "ignored secrets" pattern for local dev is kind of an antipattern, it's still super common.

Tilt should have the ability to un-ignore files that we'd otherwise ignore b/c they match a .dockerignore rule, in the service of "we don't want this file in our production docker image but we want to pull it into our dev environment for ✨reasons ✨"

(This isn't blocking @djcp but it's a generally interesting feature request, curious if others are feeling this need.)

Approaches already tried:

My first thought was docker_build(...ignore='!myfile'), but this does NOT work because we store each bit of information we get in (from your .dockerignore file or from ignore or only statements) as its own separate unit of ignore info (see code). if ANY file matches ANY of the ignore units, it fails the filter

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with internal/ignore/path_matcher.go, especially the matcher behavior linked in the issue, then trace how .dockerignore rules and docker_build ignore or only statements are combined. Define how an explicit un-ignore should override an existing rule, and add focused coverage showing that development-only files can pass the filter while remaining excluded from production builds.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
40/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.