Reading Time: 5 minutes

In this post I want to show one way that you can operationalize Fabric workspaces using Fabric CLI and fabric-cicd with GitHub Actions.

To clarify, when I say the Fabric CLI I mean the Fabric Command Line Interface. Which is a command line offering by Microsoft. Whereas fabric-cicd is a Python library that allows you to perform CI/CD of various Microsoft Fabric items into Microsoft Fabric workspaces.

I want to show how you can utilize both Fabric CLI and fabric-cicd within your GitHub workflows. In order to create new workspaces and then populate them. Like in the below diagram.

I decided to do this since the ability to copy workspace items to another one currently only works in interactive mode. You can find links to a number of Fabric CLI examples by following the links within the Fabric CLI cheatsheet.

In a previous post I shared how to do a similar strategy with Azure DevOps. So, I decided to show a GitHub version as well. With some slightly different logic. Along the way I share plenty of links.

To manage expectations, I covered how to perform fabric-cicd deployments in a previous post about operationalizing fabric-cicd to work with Microsoft Fabric and GitHub Actions. So, details about those steps will be kept to a minimum to avoid repetition.

I utilized the same variables that I worked with in a previous post that covered operationalizing fabric-cicd with GitHub Actions.

However, to introduce the concept of adding parameters as inputs in this post I added three parameters to a new GitHub workflow. Which is effectively a YAML file stored in the Git repository.

• WorkspaceName – Name of the new capacity
• CapacityName – Name of the Fabric capacity assigned for the new workspace.
• EntraObjectId – Object Id of the Microsoft Entra user to assign permissions for.

I added the parameters by adding the below inputs to my workflow_dispatch trigger:

#Sets the trigger to manual
on:
  workflow_dispatch:
      inputs:
        WorkspaceName:
          description: 'Workspace name'
          required: true
          default: 'FabricCLI'
          type: string
        CapacityName:
          description: 'Fabric capacity name'
          required: true
          default: 'Trial'
          type: string
        EntraObjectId:
          description: 'Object Id of the Microsoft Entra user'
          required: true
          default: '00000000-0000-0000-0000-000000000000'
          type: string

In addition, I decided to utilize the same Git repository that contained sample items as in the aforementioned post.

Of course, you can customize this to suit your needs. For example, you can add the service principal and tenant details as additional parameters as well. So that you can deploy and populate workspaces in multiple Microsoft fabric tenants.

You can view a sample of the “fabric-CLI-fabric-cicd.yml” workflow file created for this post in the GitHub-fabric-cicd-sample repository. Which you can download/clone and work with as a template.

Operationalize Fabric workspaces using Fabric CLI and fabric-cicd with GitHub Actions

Once prepared I started adding more logic to my GitHub workflow. First, I added the reference to the resource URL.

env:
  resourceUrl: https://api.fabric.microsoft.com

For this post, I decided to add the steps to create and populate the workspace within one workflow job. To show that you can do both together nice and cleanly if required. I did this with the below steps.

Steps to create a new workspace with Fabric CLI

My first step was to specify the Python version. Which is essential when working with Python based offerings to avoid any errors about invalid syntax.

# Use specific version of Python
- name: Setup Python
  uses: actions/setup-python@v5.5.0
  with:
    # Version range or exact version of Python or PyPy to use, using SemVer's version range syntax. Reads from .python-version if unset.
    python-version: 3.12

Afterwards I installed both the fabric-CLI and fabric-cicd libraries.

# Install necessary libraries
- name: Install necessary libraries
  run: |
      python -m pip install --upgrade pip
      pip install ms-fabric-cli
      pip install fabric-cicd

I then added another run step to login to Fabric CLI and authenticate a service principal.

# Authenticate as Service Principal for Fabric-CLI
- name: Authenticate as Service Principal for Fabric-CLI
  run: |
      fab auth login -u ${{secrets.AZURE_CLIENT_ID}} -p ${{secrets.AZURE_CLIENT_SECRET}} --tenant ${{secrets.AZURE_TENANT_ID}} 

Next, I added a step to create the workspace with fabric CLI. Specifying the provided parameter for the workspace name.

# Create the workspace with Fabric-CLI
- name: Create the workspace with ms-fabric-cli
  run: |
      fab create ${{github.event.inputs.WorkspaceName}}.Workspace -P capacityname=${{github.event.inputs.CapacityName}}

Afterwards, I added a step to add permissions to the new workspace. I suggest doing this straight afterwards so that it can be accessed even if a later step fails.

# Add permissions to workspace
- name: Add permissions to workspace
  run: |
    fab acl set ${{github.event.inputs.WorkspaceName}}.Workspace -I ${{github.event.inputs.EntraObjectId}} -R admin -f

I tested the above steps and checked that the new workspace had been created before adding the steps to populate the workspace.

Steps to populate the new workspace with fabric-cicd

In reality, these steps very similar to the steps that I mentioned in my previous post. Where I covered how to operationalize fabric-cicd to work with Microsoft Fabric and GitHub Actions.

However, I made a change to the final step runs the Python script to deploy with fabric-cicd. So that it gets the workspace Id with Fabric-CLI first and passes it through to the Python script as a parameter.

# Run script to deploy with fabric-cicd to new workspace
- name: Run script to get the workspace Id and deploy with fabric-cicd to new workspace
run: |
  $WorkspaceId = fab get ${{github.event.inputs.WorkspaceName}}.Workspace -q id
  python auth_spn_secret_AzDo.py --WorkspaceId $WorkspaceId --Environment "Prod" --RepositoryDirectory ".\workspace" --ItemsInScope  ${{vars.ItemsInScope}}

Testing the workflow in GitHub

To test running the pipeline I selected the branch that the existing Fabric items were stored in and a name for my new Fabric workspace.

Which completed as you can see in the detailed breakdown of the completed steps below.

When I checked Microsoft Fabric, I found my new workspace along with all the deployed items.

Final words

I hope that showing this way to operationalize Fabric workspaces using Fabric CLI and fabric-cicd with GitHub Actions helps some of you get started. Plus, inspire some of you to experiment in your own environments.

Because I do believe that both the Fabric CLI and fabric-cicd will be able to help with your automation and CI/CD requirements. As you can imagine if you go through the Fabric CLI cheatsheet I mentioned earlier in this post.

Of course, if you have any comments or queries about this post feel free to reach out to me.