Adventures with Power Platform: My First Deployment with GitHub Actions

GitHub and Power Platform Logo

I have deployed Power Platform solutions with the in-product Power Platform Pipelines, now I wanted to try it with GitHub Actions.

I created a Solution called ALM 2 Solution, real sophisticated name. 😄

My Solution includes these components:

  • Canvas App called ALM 2 Canvas App
  • Environment Variable called ALM 2 Environment Variable
  • Flow called ALM 2 Environment Variable Get (Power Apps)
  • Flow called ALM 2 Environment Variable List (Power Apps)
  • Connection Reference called ALM 2 Dataverse Connection Reference

Figure 1 – ALM 2 Solution

The Flow ALM 2 Environment Variable List (Power Apps) uses the Connection Reference ALM 2 Dataverse Connection Reference.

The Canvas App ALM 2 Canvas App displays the value of the Environment Variable ALM 2 Environment Variable and the results of the Flow ALM 2 Environment Variable List (Power Apps).

Figure 2 – ALM 2 Canvas App

Nothing super special here. 🪄

I created a Service Principal in Azure per Tutorial: Get started with GitHub Actions for Microsoft Power Platform – Power Platform | Microsoft Learn.

This would be the account that the deployment would run under.

I added Secrets for CLIENT_ID, CLIENT_SECRET and TENANT_ID, which I got from the Service Principal.

Then, I added Variables for DEV_ENVIRONMENT_URL and PROD_ENVIRONMENT_URL, these held the URL for the Power Platform environments.

Figure 3 – Secrets and variables

In creating my Workflows I followed a lot of the instructions at Tutorial: Automate solution deployment using GitHub Actions for Microsoft Power Platform – Power Platform | Microsoft Learn, but did make a few tweaks.

I created a Workflow called export. ⚒️

It exports both a managed and unmanaged version of the solution.

Then, it unpacks the unmanaged solution.

After that, it commits the changes to a repository.

Eventually I will trigger this off of a GitHub release, but for now, I wanted to manually trigger it.

I create another Workflow called release-to-prod, that would deploy the Solution to the production environment. ⚒️

In GitHub I navigated to Actions, clicked on export and clicked Run workflow to run the workflow.

Figure 3 – Run export workflow

Once the export workflow was completed, I clicked on release-to-prod and clicked Run workflow.

Figure 4 – Run release-to-prod workflow

I need to share the Canvas App with my user account, so I can run the application.

Figure 5 – Share the app

When I run the Canvas App in the new environment, I get errors. 😟

  • Missing value for the environment variable ‼️
  • Missing connection for the connection reference ‼️

I could manually set the value and the connection but would prefer this to be automated.

I came across the article Pre-populate connection references and environment variables for automated deployments on how to create a DeploymentSettings.json file that can be used during the import.

I created a Settings folder in my repository and then in that folder, created the DeploymentSettings.json file.

To get the ConnectionId value, I navigated to the Connection in Power Apps Studio and grabbed in from the URL.

The URL is in the format of https://make.powerapps.com/environments/ENVIRONMENT_ID/connections/shared_commondataserviceforapps/CONNECTION_ID/details.

Figure 6 – Connection

The connection I wanted to use in my production environment uses a service principal for authentication.

See A Visual Guide To Power Platform Service Principal Setup for how to do this.

I updated the DeploymentSettings.json files with the Value for Environment Variable and the ConnectionID for the Connection Reference.

I updated the release-to-prod workflow to use the DeploymentSettings.json file.

I updated the Import solution to destination environment step and set use-deployment-settings-file to true and deployment-settings-file to Settings/DeploymentSettings.json.

In GitHub I navigated to Actions and ran the release-to-prod workflow.

Uh oh! The workflow generated an error. 🤔

Figure 7 – Workflow error message

As you can see the error message is super helpful … not! 😡

I struggled to figure out what was going on, then I remember with the in-production Pipelines, when you did a delegated deployment with a service principal you had the choice to check a box to share the connections with the service principal. 💡

Figure 8 – Sharing the connection with the service principal

I reran my release-to-prod workflow … drum roll … the deployment was successful! 🥳

Figure 9 – Successful run

I am sure there are a lot of tweaks I can make to my workflows and process in general, but for my first attempt at deploying with GitHub Actions, I’ll take it! 👏


Discover more from Matt Ruma

Subscribe to get the latest posts sent to your email.

Leave a Reply

Your email address will not be published. Required fields are marked *