Set Production branch to something other than master

(Michael Dunn) #1

Request: Add the ability to select a branch other than master as the production branch for a project.

Reasoning:
I have separate Dev and Prod Looker instances, with GitHub webhooks set up as described here (TL;DR: on-push webhook pings the Dev instance, on-release webhook pings the Prod instance). This is nice in that it lets us make sure changes from various branches have been tested to work together before releasing it to end-users. The problem is it makes it harder to fix bugs in production.

Suppose release 1.0 is in production. A lot of work has been done on 2.0 since then, with several features having been merged into master but not released to production. A significant bug is found in 1.0 that needs to be fixed urgently. What now? Because Looker locks master as the production branch, I’m forced to do one of three things:

  1. Don’t fix the bug in 1.0, leaving it for the next release, whenever that is.
  2. Revert from master all of the changes since 1.0, merge the bugfix into master, release 1.1, then re-commit all the work to master.
  3. Merge the bugfix into master, then release 2.0 before it’s ready.

If I can have the Dev instance use develop as its production branch while the Prod instance continues to use master, I can make a new branch fix-broken-thing from master, make the change in fix-broken-thing, then merge fix-broken-thing into both master and develop without any of the above issues.

I could use a different branch management strategy where all of the 2.0 feature branches are merged into a foo-2.0 branch instead of master, but that requires:

  1. Everyone to be in dev mode and switch to the foo-2.0 branch to see what’s in 2.0, and
  2. Changing GitHub’s default branch settings (I wonder if Looker explicitly checks out master or if it just uses the default. If it’s the latter, this would mess Looker up), or
  3. Everyone remembering to not create their Pull Request against master. We end up fighting with tools when we should be building stuff.

I would think it’s a pretty simple feature to add, and it would allow people to apply the GitFlow branch management strategy to Looker.

6 Likes

Overview: Git and Looker
Develop mode for Embed users
(Theo Geer) #2

+100 or so
I’ve been pondering the best way of managing / solving this problem off and on for about a week and thought to come here for answers today. :smiley:

0 Likes

(Kevin Marr) #3

Makes a ton of sense, and thanks for the great write-up. This is something we definitely want to address soon, although it’s not on the immediate roadmap.

I may reach out when we start scoping out some solutions, if that’s alright!

Best,
Kevin Marr
Product @ Looker

1 Like

(Michael Dunn) #4

Thanks Kevin.

I hope you guys decide to pick this up sooner rather than later. It seems like a really straight-forward change that 1) adds a lot of value to have in place in terms of platform flexibility and developer time saved, 2) prevents a lot of value from being realized without the change, and 3) fixes what was an inexplicably strange design choice to have made in the first place.

Can I bribe you guys with beer or cookies or something to encourage you to add this feature in the near-term? Because I will totally have something delivered to your office if it’ll help. I’m not above bribery. :slight_smile:

In the meantime, would you guys consider updating your documentation?

This page says:

for projects where the production branch is decoupled from the master branch, such as configurations with a staging instance used for testing

This page says:

From the Branch Management tab you can delete branches that have a Delete button in the table. You cannot delete the following branches:

  • The master branch
  • The production branch (in most cases, the production branch is the master branch)

These both suggest that its possible to have something other than master as the Production branch. As that’s apparently not the case, the docs should be corrected to reflect reality.

1 Like

(Yuriy) #5

Hey Michael.

+1 for this issue since this should be a normal git workflow.
You may find useful this page as a temp workaround https://gist.github.com/Chaser324/ce0505fbed06b947d962
This is what we do for our multiple environments:

  1. We have a separate group in git for each Looker env.

  2. Set up this process in uDeploy or other tool for each Looker project

     echo “Project: ${p:project_name}”  
     echo “Default git source group: ${p:git.sourceGroup}”  
     echo “Git target group: ${p:git.group}”
    
     # Remove previous folder
     rm -rf ${p:project_name}
     
     # Clone the your fork to udeploy agent
     git clone git@git.company.com:${p:git.sourceGroup}/${p:project_name}.git
     
     cd ${p:project_name}
     
     # git add remote source
     git remote add ${p:git.group}     git@git.company.com:${p:git.group}/${p:project_name}.git
     
     # Verify the new remote named 'upstream'
     git remote -v
     
     git push ${p:git.group} master
    
     ## After this, have another process to trigger looker deploy webhook
     echo "Deploying Node1: ${p:node1}"
     URL="--no-check-certificate --output-document=${p:node1}.json     https://${p:node1}.company.com:9999/webhooks/projects/${p:project_name}/deploy"
     wget $URL
     if [ $? -ne 0 ] ; then
       echo "Received error calling wget"
       echo "Please email looker@company.com with the failed process link"
       exit 1
     fi
0 Likes

(Devin Zuczek) #6

We use the embed user functionality pretty heavily, this would also help there since you can only currently login as an embed user and use the production branch: https://discourse.looker.com/t/develop-mode-for-embed-users/11147

0 Likes