Looker will not be updating this content, nor guarantees that everything is up-to-date.
Starting in Looker 7.12, you can deploy any Git commit SHA, tag, or branch to production with Advanced Deploy Mode. This helps consolidate repositories in multi-environment developer workflows, where each environment points to a different version of a codebase. It also gives greater control to one or a few developers or administrators over the changes that are deployed to production.
By setting up a Git workflow across multiple Looker hosts, we can create a dedicated development environment for developers to work in, all while shielding users from being exposed to any experimental code. All development and code review is done in a development or staging environment, and once changes pass your team's quality assurance, they are deployed to staging or production as desired.
This article describes two different methods of setting up a workflow among multiple instances, depending on whether you have:
- Multiple instances and one repository (explained in this article)
- Multiple instances and multiple repositories (explained in Git Workflow Using Multiple Repositories Across Multiple Instances—Development, Staging, and Production)
Looker recommends using a single repository whenever possible.
Setup with a Single Repository and Pull Requests
First, we'll describe how to setup an environment that has multiple Looker instances (development, staging, and production, for example) with pull requests enabled.
This option is currently only available if you are hosting your Git repository.
Starting in Looker 7.12, the following actions are available on the Configuration tab of the Project Settings page. Navigate to the Project Settings page by clicking the Settings icon from the navigation bar.
Pull requests are configured on the Project Settings page, found on the drop-down menu in the LookML section:
This will open the Project Settings page, where you can select either Pull Requests Recommended or Pull Requests Required:
Next, create the trigger on the webhook, as shown below in Git interface:
This configuration will allow the lead developer to approve pull requests from the Git web interface, where the webhook will push changes to production.
Starting in Looker 5.20, you can add a secret for your deploy webhook. See our documentation for more information.
You can create a second release webhook to trigger an update to production, manually deploy to production by going to the webhook URL when you're ready to deploy, or base your trigger to production on available Github events.
I’m sorry but this article seems to be incomplete. There are important issues not discusses: