What are the best practices for managing Looker's repo?

We have a repo with a huge amount of best practices “hooks” associated with it:  hundreds of SonarCloud rules, checks for too much code duplication, etc.  This includes, at a very basic level, being able to protect a GitHub repo branch so that no one can push to it directly.

I would ideally like to use this same repo for my LookML code, but because LookML is so tightly coupled with version control, many of these things don’t work.  For instance, it seems that protecting a branch is not possible:
 

https://community.looker.com/technical-tips-tricks-1021/error-failed-deploy-rejected-other-reason-pr...


With core GCP, even with data tools that are not originating from Google, there is much looser coupling.  For instance, with GCP Composer, I can put all of my DAGs in my normal repo, and I just make sure that Airflow / Composer is sync-ing with the right folder in the repo, and everything else is fine.  (There is a minor hoop I have to jump through to ensure that utility code is properly added as a “plugin”, but all else is fine.)

==========

I have a question to Google:  what are the plans for decoupling Looker so that it treats repos similar to how other GCP products handle it?

But I know that this will be a very long term solution.  So, in the mean time, I wanted to know what other best practices the rest of the community uses.  For instance:

  • Do you always use a separate repo for LookML code?
  • Does that repo always need far looser rules / hooks, etc.?
  • Do you have some manual controls to ensure that there are no mistakes?

I simply want to know, how do you ensure production-level stability when working with Looker?  It does not seem to allow for all of the tools to ensure rigor towards to repo than I would otherwise expect from software tools in 2023.
 

0 1 241
1 REPLY 1

Is there any way to get folks on the Looker team to look at this?  Specifically, now that I’ve heard that a new release of Looker is coming out May 8th, I’d like to know how close we can get to properly integrating Looker with our git best practices, etc.