Impact of subfolder with non-LookML code

Hi!

We’re thinking of creating a subfolder in Looker’s main folder (where all LookML resides), and that subfolder would contain non-LookML code we use for data modeling, or data transformation (mainly SQL files, but also shell scripts, yaml files, and potentially other file types).

The motivation is to have LookML and data modeling code live in one single place, which would allow us to build automated tests to check that changes in our data modeling plays well with Looker, and vice versa - which is incredibly hard to do if the two things live in different places i.e. 2 different repositories.

Questions:

  • Is there any known negative impact of having a subfolder with lots of LookML-unrelated, e.g. on Lookers LookML validator, or on Looker’s git integration?
  • Is there anyone out there who has tried that?

Thanks all.

Looker only ingests certain kinds of files, AFAIK— “.lookml”, “.lkml”, “.yml”, “.md”, “.json”, “.topojson”, “.geojson”, “.svg”, “.strings”, “.gitkeep”.

So, as long as the files in the repo aren’t of those types, then I don’t think Looker will even see them. If you have a whole other subfolder, though, I think there’d be no way to prevent that from showing up in the IDE which would be annoying.

I’d say generally not recommended due to organizational simplicity, but I don’t think it’d cause any huge problems.

Thanks, @izzy. We’ll try it out.

Also, and this definitely isn’t a reason to do something that might not be a best practice— But since Looker expects all file changes to be made from within Looker, if you add files directly to git outside of the IDE, Looker actually won’t track those unless you hit the deploy webhook.

So, unless you have a git workflow with Pull Requests that requires you to regularly hit the deploy webhook, the non-lookml files you throw in the repo actually won’t ever get tracked by Looker. So don’t be surprised when they don’t show up :slight_smile: