Hey @mattmoor I'd like to take this one up but before that I want to clarify with you. Let's say I have this structure:

- foo
- | - .ko.yaml
- | - k8s.yaml
- | - bar
- | - | - k8s_inside_bar.yaml
- | - | - .ko.yaml

Are we expecting to use foo/.ko.yaml for foo/k8s.yaml only and then use foo/bar/.ko.yaml for foo/bar/k8s_inside_bar.yaml?
Or are we using only either one of foo/.ko.yaml or foo/bar/.ko.yaml (if this is the case, which one has higher priority)?

I think this could spiral quickly, so I think as a first increment let's start with three simple pieces:

1. Log if/where .ko.yaml is being read from,
2. Support a flag to override that,
3. Walk up the directory hierarchy and pick the first (vs. today, which only does current dir)

I think this balances clarity and simplicity. WDYT?

I'm totally behind reading from only one .ko.yaml as I love to keep things simple. One question though, by "walking up", you mean we search parent directories? If that's the case, I'm seeing some complexity on how we determine when to stop searching?

I'd probably do the simple thing: keep going until you hit the root, or start getting permissions errors 🤷

I'd probably do the simple thing: keep going until you hit the root, or start getting permissions errors 🤷

One edge case that might end up confusing to end users (small problem since we're logging the location out but I'd still like to raise it): Say I have project2 as a subdir in project1, something like:

|- project1
|- .ko.yaml
|- project2
|- |- k8s.yaml

Now if I run ko apply -f k8s.yaml inside project1/project2 with the intention of using environment variables, I would be out of luck because the config (with the above-discussed behavior) would be read from project1/.ko.yaml.
I understand that the above scenario is an extreme one and most likely would not happen for majority of our users, but I'd still like to check if it's small enough for us to ignore. Also, we might need a flag value to indicate not reading from .ko.yaml for the mentioned scenario