PBI & Git Integration: Add PR option to Button within Online Workspace

[Tim_Briggs]

Hi Community,

As someone who has taken advantage of the .pbip folder structure and git integration with PBI I am very pleased with the functionality but I have noticed a few items that would be an improvement over the current setup. For reference, I am utilizing a general workflow of staging branch linked to dev workspace, main linked to prod workspace, devs create feature branches from staging and then PRs are opened into staging from feature and then PRs off of release branch from staging is opened with main. On each successful commit to staging or main a github action runs that syncs the branches contents with the online workspace. Now this brings me to my point, there are times when devs would like to make a minor change directly within the workspace. I want to get this changes tracked and incorporated in git; however, there is currently only the option for commitng directly to the linked branch or creating and commiting to new branch (and then you could follow the stated dev cycle I outlined above assuming you create a new branch) BUT it would be greatly appreciated if you could open a PR from what is in the online workspace with the linked branch because my staging and main branches are protected and no commits can be made directly to then without review.

I am curious if anyone else has a similair experience or if this would be helpful for them? Please a few screenshots below for reference. 

Any interaction on this post is greatly appreciated.

[frithjof_v]

For clarity: by Online workspace, do you mean the Dev workspace (linked to staging git branch) or the Prod workspace (linked to main git branch)? Is the Idea that if someone makes a change directly in the Prod workspace, you want to merge that change back into your staging git branch and main git branch?

I would encourage to use feature workspaces for all changes. Why do they need to make changes directly in the dev or prod workspaces?

In your scenario, if you really need it, could you use the 'Commit to new branch' option in your Prod workspace to create a new git branch containing the changes, and then merge that new git branch into your staging git branch using a pull request in GitHub?  

Essentially, you would allow the developers to make changes directly in the prod workspace, bypassing the ordinary git review process, then commit the changes to a new git feature branch and then make a pull request afterwards to get the changes (which have already been applied in production) reviewed and merged into Git staging and main branches.

I have never tried the 'Commit to new branch' option myself, but it sounds relevant for your scenario.

And you mention it here: "there is currently only the option for (...) or creating and commiting to new branch (and then you could follow the stated dev cycle I outlined above assuming you create a new branch)". Why can't they do that? Is the primary benefit of the Idea that the user would not need to switch over to GitHub to create the PR? Is the idea that a new button will both 1. commit the changes to a new branch and 2. automatically creates a PR to merge the new branch into the staging branch? (On the other hand, if the idea is to create a PR without even creating a new branch first, I don't think that's possible in Git. That's a Git limitation, not a Fabric limitation.)

As mentioned above, I would strongly encourage using feature workspaces for all changes, instead of making changes directly in dev or prod workspaces.

Just for context: I'm not familiar with the exact workflow that you're using, but I assume your GitHub action uses the Fabric Git Integration REST API to sync changes from the staging git branch -> dev workspace and from the main git branch -> prod workspace. By your description, my understanding is that you're not using Fabric Deployment Pipelines (which I do) or the fabric-cicd python library.

[Tim_Briggs]

Hey @frithjof_v, thank you for your thoughtful response. Your summarization of my inquiry is correct. When you phrase it like you did with your paragraph starting with "Essentially, ..." that hit home. Yes, I'm aware of all the benefits of source control and ci/cd yada yada - I was only thinking of the case of making the smallest of changes and not wanting to go through the dev cycle (I was just being lazy). But you're right, as things scale that isn't the best method. The idea was basically to just have a one-shot click of hey I made changes in my online workspace I would like to have these incorporated in the linked git branch I am using (really only for the edge case though of a minor change). To your point, I or other developers can take advantage of creating a new branch and commit to it via the button that exists now and then follow the stated dev process. And yes, I get your point theoretically of doing all development in feature branches - I am all for that - but I haven't figured out a way to turn off the ability for devs to make edits on the online workspace ... and nor do I want to in the case of a hotfix that is required. Although I'm curious, do you know if it's possible to turn the ability to edit in the online workspace off? More just curious. And yup, you're correct again, I'm using the update from git method that you linked. If I may ask, why did you decide to go with fabric deployment pipelines instead of using the fabric api? Potential Intro: You seem to have great knowledge on pbi - I'd be happy to connect offline or via a call to pick your brain and share my experiences if you're interested as well. Thanks so much!

[frithjof_v]

"Although I'm curious, do you know if it's possible to turn the ability to edit in the online workspace off? More just curious."

It's not possible, unless using permission control. Some teams do that, giving only special privileged accounts access to the Online workspaces. Some teams place that access behind PIM (Privileged Identity Management) control using a PIM-enabled security group. This means it's hard for humans to access the Online workspaces, and they use Service Principals to actually run the items in the Online workspace.

But yeah, there are no direct ways to make Online workspaces read-only. I made an Idea for it, though, allowing Admins to use a toggle to make a workspace read-only or allow edits: https://community.fabric.microsoft.com/t5/Fabric-Ideas/Make-production-workspace-items-read-only-edi...

"If I may ask, why did you decide to go with fabric deployment pipelines instead of using the fabric api?"

Mainly because we've used Fabric Deployment Pipelines with Power BI, so we were familiar with them. We're using Option 3 here: https://learn.microsoft.com/en-us/fabric/cicd/manage-deployment?source=recommendations#option-3---de...