This article has been retired as the information is now in documentation on this page.
How to use Git in Looker
How Does Push To Developer Branch Work
How to revert pull requests from Looker via Github (3.20+)
Does this only work with Github? I don’t see the options you mention in Looker 3.20.10. We’re hosting our own Git repository (Atlassian Stash).
We expect it to work with Stash (but would love for you to verify). But first you’ll need to run the git setup through the Looker UI. After you click
Git Settings you should have the option to ‘Reset your Git Connection’. Resetting the connection should make it so the options appear for you.
Let me know if that works.
Thanks Margaret. I’ve tried resetting the connection. and also setting up a new project.
However I still don’t see the options when selecting Custom Git Configuration. I can see the new options with the Bitbucket service type but alas that doesn’t seem to work with Stash.
Hi Andrew, think I might have found at least part of the issue.
Can you ensure you are selecting “Bitbucket” rather than “Custom Git Configuration” when doing the Git setup? I think this might be the culprit.
(For reference to others, here’s the guide on configuring Git services: How to Configure Git in Looker (3.18+))
Ah, so it doesn’t work for Custom Git Configuration?
If I use Bitbucket, it strips out the port during Git set-up (which is required to connect to Stash).
As a side note, it also generates web links in the Looker UI that are incorrect for Stash.
Ah, the port number may be getting improperly removed. Would you mind sending a quick email to email@example.com with some information so we can follow up?
It’d be awesome to know:
- The URL you’re pasting into the Git set up
- The URL Looker is generating for Stash
- The URL Looker should be generating for Stash.
We recently set Looker up with Stash. We used the Git Enterprise setting. We passed in the clone URL from the Web UI and configured the access key. Basic functionality appears to work. There are some issue though. Stash uses a different path in the browser to what is provided by the clone link meaning that parts of the URL links to show history etc when requiring pull requests fail. If seems like a new drop down item needs to be in Looker that says Stash Enterprise with most but not all of the same set up under the covers as the Git Enterprise setting. Stash adds /project, /PROJECTKEY and /repos in the web path. For example. https://stash.somedomain.com/projects/PROJECTKEYNAME/repos/looker
So there needs to be a way to configure your PROJECTKEYNAME and Looker handle the addition of /project and /repos so all the history and pull request links work without you having to change then manually.
This doesn’t seem to match our common use case for pull requests:
- Developer gets a story
- Developer, starting from master, creates a branch for working on that story specifically
- Developer creates code for that and tests it
- Developer creates a PR for that branch.
- Developer goes on to the next story
- Lead developer reviews PR and maybe merges, maybe doesn’t.
Note that after 4 and before 6, developer needs a new branch. If the PR is rejected, the developer needs to change branches in order to work on the old branch without polluting it with the new story’s work.
The Looker 3.20 approach where a developer has one and only one branch does not match up with the asynchrony and distributed development model encouraged by
git; we’ve had to retain our older system of managing releases with a lot of forks, scripts, and external engineering discipline.
We just enabled this and, after the pull request has been merged in Github, I have to go back to Looker and “Pull from production”. Is that the expected behaviour? I just wanted to check it’s working as it should.
Also, what is the webhook used for? I had this set-up incorrectly initially and the process seemed to work the same before and after.
Where it is asking for a pull is actually your developer environment. The webhook is designed only to trigger a pull for the production model on a Looker instance. We do not have a way to trigger pulls for developer environments because this could cause confusion to LookML developers as changes are being made.
Let me know if you have further questions or concerns!
Tried setting this up.
What if I’m getting an error in Github when I add the webhook that says “Last delivery was not successful. Invalid HTTP response: 0.”
FYI, if you turn on Pull Requests with GitHub, each Looker developer who wants to open a PR will need to have a GitHub account.
Without this, the PR will never be opened.
Echoing everything that Rick Cobb said that this flow does not match best practice for development.
Echoing everything here. Trying to get PRs from our looker dev to our looker prod instances is a nightmare. There is no way to do it easily: I had to resort to cherry-picking commits out of the dev repo by setting it as an upstream source for PROD. And even with this method there is no QA possible.
One step in the right direction would be to allow users to indicate what BRANCH of the repo to base an instance off of. This wouldn’t solve all the steps above, but it would start to make the use of git-flow possible.
Sorry to jump on the bandwagon here too, but I share this sentiment. The way PR’s work right now is just not quite there yet to be usable or even worth using Pull Requests at all. The only way you can really use this is if you merge your own pull requests right after creating them, since any changes you make after that will be based on the same branch.
To explain a bit more, here is a more detailed example of what I want to achieve:
- Make a change for issue A. Commit those changes, create a new PR asking for review (before the PR is merged)
- While waiting for review, make changes for issue B. Create a new PR for this.
This is where I get stuck. Since my first PR hasn’t been merged, I can’t make any changes that won’t go into the previous PR.
As well as this scenario:
- Someone on my team submits a PR, I want to checkout their pull request in my local development environment and make additional changes before merging it to master.
Basically, the idea that you only have single dev branch per user and that Pull Requests are based on that branch is the problem. If instead you created a new branch for each PR and have the ability to ‘check out’ those branches locally, you would be able to solve these issues, and actually make this feature useful.
Once pull requests are enabled it is worth familiarizing yourself with the Github documentation on approving pull requests:
To add to what JohnRomanski and Michael_Erasmus have already said (which I +1 all the way):
In addition to being able to have multiple working branches per user, it would be nice if merging a pull request didn’t automatically deploy to production. Right now, we have our staging and prod looker instances pointing to the same repo. Because we can’t configure which branch production syncs from, we either have to accept that merging a PR deploys to prod in an otherwise uncontrolled manner, or we have to make a 2nd repo for prod and manually merge changes from the staging repo to the prod repo. Doable, but less than ideal. An alternate approach would be a scenario where prod doesn’t automatically sync and the action has to be triggered by an admin manually.
@jfhbrook You can set up a workflow where merging a Pull Request in the Github UI does not automatically deploy that change to Production mode in Looker.
The directions above outline how to set up a webhook that is triggered when anything is pushed to master. This webhook forces Looker to pull from master in Production mode, so that Production is always synced with master.
But you can modify or remove this webhook in any way you’d like!
For example, you could remove the webhook and then manually go to that webhook URL in your browser if you’d like to manually manage when Production is deployed to.
Another option is to utilize the releases feature on Github only trigger the webhook when a release is created (this option is under the “Let me select individual events” selection when creating a webhook).