NIEMatron

Keeping a Fork in Sync with the Original

While opensource projects are meant to allow contributors to create modifications and submit those modifications back upstream, the process for doing so isn't always clear. In a rapidly changing source repo, making a fork and keeping that fork in sync with the upstream (original repo) just so that you can submit a pull request can be tricky if one doesn't know about a few tricks. This article explains one of those tricks in keeping a copy of the upstream repo as the master branch locally on your PC while your new feature branches pointed at your forked repo.

Step 1 - Fork the Original Repo

Most open source projects do not allow you to create a branch in the master project, which requires contributors to fork the original repo so that you can make changes there first before submitting the change to the upstream repo in the form of a pull request. The first step is to of course fork the original repo. In GitHub, this can be done by clicking on the Fork icon at the top of the open source project you are working with.

Step 2 - Clone the Original Repo to Your PC

Once the fork is created, its time to clone this or the upstream repo to your PC so that you can create a new branch and begin editing the source code. The clone can be done from either the fork or the upstream repo. Either will work as we rebase-ing the fork with the upstream on a regular basis.

git clone [your clone URL here]
# assuming the clone was the upstream do the following to rename it to upstream
git remote rename origin upstream

Step 3 - Point Master Branch to Upstream

Now that we renamed the origin to upstream, we need to ensure that the master branch we obtained still points at this upstream repo (and not our fork). this is done by:

git branch -avv # existing branches like master are linked to upstream/xxx

Step 4 - Add the Fork URL as a new Remote

Now we need to add back in a new origin pointing at our fork so that all of our new branches point back to the fork and not the upstream repo.

git remote add origin [your fork URL here]

Step 5 (Option a) - Checkout a new Feature Branch (For New Branch in Fork)

Now we have our two remote created, we simply checkout a new feature branch to begin our work.

git checkout -b [Your Feature Branch Name]

Step 5 (Option b) - Pull and Checkout Feature Branch (For Existing Branch in Fork)

If you already have a feature branch in the Fork, we'll need to pull it to our local machine before we begin our work.

git pull origin [Your Feature Branch Name]
git checkout [Your Feature Branch Name]

Step 6 - Rebase Master

Now before any commits are completed, you will need to synchronize the master with the upstream repo and rebase our fork to the latest changes in that parent repo. Since we aren't making changes directly on master anyway in our fork, we will be using the Rebase command, which ignores any changes in master on your PC and will replace it with what is checked out from the upstream repo.

# switch to the master branch
git checkout master
# pull recent updates from upstream
git pull upstream master
# switch back to your forked-based feature branch
git checkout [Your Feature Branch Name]
# rebase the fork's master branch with the upstream master
git rebase master
# push the rebased master back up to our fork living in our fork remote
git push origin master --force

Step 7 - Commit and Push Changes to Fork

Assuming the changes are complete and the above step was completed moments before this step, just commit the code changes you made and push them to the fork.

git push origin [Your Feature Branch Name]

Step 8 - Submit Pull Request

As you return to GitHub or whatever cloud-based git repo you are using, submit your pull request to the upstream owners for their review and inclusion in a future version of their code. It's good form to do this as quickly as possible in order to avoid any chances of significant code changes coming into play before the pull request is reviewed.

Update 5/29/19: Adding descriptive/instructional link to rebase step.

Update 6/20/19: Adding Option a and b for Step 5

In working with a number of developer-heavy customers, there seems to be a strong demand for taking the reports and dashboard developed in PowerBI and publishing them in either Intranet or Internet web pages. This concept is currently known as PowerBI Embedded and comes in several different options for developers to implement.

Licensing and Disclaimer

Before we start, I will note that there are definitely licensing concerns and implications to choices made as a part of this tutorial. While I could likely articulate the current rules surrounding PowerBI licensing, there are a variety of options and I am not truly qualified to explain all of these nuances. . . .so I won't even try.

PLEASE seek assistance from your Microsoft account team if you choose to Embed PowerBI in your applications to determine what licensing model works best for your organization.

Additionally, technologies frequently change. I will make every attempt to update this tutorial as functionality and technology changes, however for the most current up-to-date information, you should always refer to the Microsoft PowerBI developer documentation, and never any individual tutorial (including this one).

Step 0: Make Some Choices

Before we begin, lets discuss some of the options available to developers who are trying to embed their report. At it's simplest, developers can place their PowerBI reports in a web page by using an HTML IFRAME on their site and ensuring they have a pointer to the correct PowerBI report. Here are a simplified list of options:

Option A - Publish to Web

The simplest way to get a PowerBI report into your website is to use the "Publish to Web" option in PowerBI.com. Just publish your report from the PowerBI client application, and from the File Menu choose "Publish to Web". This is an entirely public method of publishing though, and there is NO way to lock down ANYTHING.

Option B - User Owns Data

The second option is currently termed "User Owns Data", and in this model, each user who logs into your website with a valid Azure AD account will be allowed to see what they're permitted to in any given PowerBI Report. Great for Intranet sharing where you know all of your users and trust their Azure AD sources.

Option C - App Owns Data - FOCUS OF THIS TUTORIAL

The third option is currently known as "App Owns Data" and leverages what is essentially a single service account to publish the report as that service account user. Great for situations where you are publishing a report on a public website where users will not be logging in before they see your PowerBI report.

Assuming you chose to go with Option C above, the rest of this tutorial will walk through how to implement this. You can also follow the tutorial linked in the Option C section above, but these steps should simplify the official tutorial some more.

Step 1: Develop a PowerBI Report

While it may seem obvious, this first step is important to leveraging some of the tools to their greatest extent. You can change your specific report later, however for the purpose of following the PowerBI Embedding wizard, it's easiest to have a .pbix file on hand as you embed your first report.
The easiest way to develop your first report is to download the PowerBI client and create a report to embed. If you haven't done so already, you may download the PowerBI client from powerbi.com.

Step 2: Obtain a Service Account

This approach assumes that a service account user will be logging into PowerBI on behalf of your application, therefore, you will need to have a fully licensed PowerBI user [with password] created. Speak with your organization's Azure AD administrator and have them authorize the new user for PowerBI in the Office Portal (portal.office.com).

Step 2a -Test Logging In with Service Account

Just to be sure your user was provisioned correctly (and has access to PowerBI), PLEASE login to Powerbi.com with your new user and ensure they can use or see a report (ideally the one you created above in Step 1).

Step 3: Use the Wizard!

The PowerBI product group recently developed an amazing wizard to walk users through the process of creating and embedding reports in your website. Navigate to the wizard at https://app.powerbi.com/embedsetup and choose the option labeled "Embed for Customers". If you are using PowerBI Government, the same wizard is available to you at https://app.powerbigov.us/embedsetup.

The following are some important notes for as you walk through the wizard:

Step	Note
Step 1 - Sign In	Sign in with your new service account. If you do not login with your service account, your "user" will never have the chance to accept terms and conditions (Step 5), and you will get some strange unauthorized error in your code.
Step 2 - Register Your Application	The PowerBI report you are creating needs to be registered in Azure Active Directory so that OAuth can be used to verify your user has rights to the report being published. The official Microsoft tutorial goes into great detail on what this means and why, but for now, just give your application a name so that it gets permission to use the embedded objects.
Step 3 - Create a Workspace	Even though you probably already have a PowerBI workspace, just let the application create one for you. Your code can be updated later.
Step 4 - Import Content	Same as above. Even though you've probably already created a report, just for now, provide it a .PBIX file so that it creates another one for the sample source code that comes out of the wizard.
Step 5 - Grant Permissions	Since this service account is acting like a user, and every user needs to accept terms and conditions when using Azure AD for Oauth. . . .you'll need to allow your application and user to be related with one another in this step.

Upon completion, you should see an option to download sample code. Download this .zip file and unzip it somewhere you can open it in Visual Studio 2015 or higher.

Step 4: Modify the Sample Solution Code

Open the .sln file you just downloaded in Visual Studio and navigate to the web.config.

Step 4a - Add Password to Web Config

The solution should have everyhing you need. . . EXCEPT a password. While we should NOT publish this code (nor check it into source control) with a password in our code, for now we just want to be sure everything is working. Add your password to the AppSettings section where you see the blank.

Step 4b - Restore NuGet Packages

From the Tools Menu, navigate to the NuGet Package Manager and choose the option to restore packages not currently in the solution.

Step 4c - Update NuGet Packages (Optional)

If you will be publishing your work to a modern web server, you will likely want to update your packages to ensure any vulnerability and server-side incompatibilities are addressed before being published.

Step 4d - Build and Run

If it worked, you should see a set of 3 buttons. . . if you pick Embed Report, the following should show without an error:

Step 5: Secure Your Identity

Now that we know it works, you will now want to go through and hide your service account's login in something other than plain text in the web.config file.

In the next article we will go through the options for securing your identity if you are using an Azure Web Service. Stay tuned!