A guide to the 19 inputs for the import-solution action in the Power Platform GitHub Actions

When working with the Power Platform Actions for GitHub, there’s only a few inputs we need to commonly populate to achieve typical or standard requirements to automate solution deployment with the import-solution action in a workflow using GitHub Actions, however there’s an whole 19… READ MORE [htt
pexels-photo-14806236.jpeg
Photo by Mathias Reding on Pexels.com
In: Low Code Lewis Content 🚀

When working with the Power Platform Actions for GitHub, there’s only a few inputs we need to commonly populate to achieve typical or standard requirements to automate solution deployment with the import-solution action in a workflow using GitHub Actions, however there’s an whole 19 inputs that we can utilise to achieve different things when using the action!

In this post, I’ll give you a guide to the 19 different inputs you can utilise for different things when using the import-solution Power Platform action in a GitHub Actions workflow 💯

Authentication

The first five inputs we can use are for authentication, which we always must use two or three of. We also only ever need to use two or three of them. The five inputs include two groups, each of which on their own will support authentication against an environment for importing a solution.

user-name:
password-secret:

The first two inputs we can use to authenticate are a username and password. I would recommend using the next three options though which are…

app-id:
client-secret:
tenant-id:

Using the three inputs above we must authenticate with an app registration which we create in Microsoft Entra ID, which we then add as an application user in our environment and assign a security role to. Check out the following post to understand how to resolve the first step of authentication.

Cloud type

So the next input we have is also for authentication and allows us to provide the type of cloud we’ll be authenticating to for cases where its not just a simple business or enterprise tenant. This might include cloud or tenant types such as government tenants.

cloud:

Here are the values…

Public, UsGov, UsGovHigh, UsGovDod, China

Solution file

This input is one we’ll always have to use to supply the solution that we want to import to our target environment. We have to provide this input with a path to a .zip solution file. When working with GitHub Actions and a GitHub repository, if you’d like to make this simple, simply upload and commit the .zip file to the top level of your repository, and then just reference the file name with .zip extension in the input, providing your repository location is the working directory.

solution-file:

Activate plugins and workflows

Ever noticed the checkbox on the import solution pane which allows you to ensure plugins and workflows get switched on during a solution import? The next input allows you to control this when using GitHub Actions to do your solution imports!

activate-plugins:

This input simply takes a true or false value, true meaning that the plugins and workflows will import and switch on, and false meaning plugins and workflows won’t get switched on.

Remove unmanaged layers

The next thing we’re able to do is overwrite any unmanaged layers with a solution import! If you’ve created unmanaged layers on your solution objects by editing them in the environment where the solution has been imported as managed, say a test or production environment, then by using the next input, you’ll be able to overwrite these unmanaged layers with the solution import you do! Here’s the input…

force-overwrite:

This input also takes a true or false value.

Don’t check for dependencies

The next input will allow you to skip dependency checks on product solutions which have been marked as having an update. The input is…

skip-dependency-check:

This is another input which simply takes a true or false value, like a checkbox.

Import a solution as holding

The next input allows us to import a solution but not apply the upgrade. This input lets us import a solution as holding so that the updates don’t get applied, but we’re able to apply them later with another command or by selecting the solution followed by selecting the ‘Apply Upgrade’ button in the solution viewer GUI.

import-as-holding:

This is another input which we simply need to populate with a true or false value.

Publish changes

Need to ensure changes are published following an import? Simply populate this next input with a true value…

publish-changes:

Working directory

Want to set your working directory to something other than the default which is the root of your repository? Simply provide the directory to the following input. Keep in mind this will affect other inputs which use the working directory such as the solution file.

working-directory:

Run asynchronously

This isn’t an input I’m so worried about using but simply lets you determine whether a solution gets imported as an asynchronous process or not. Let me know in the comments if you’d use this, and what for!

run-asynchronously:

Resolve connection references and populate environment variables

When we import solutions which contain connection references and environment variables through the Dataverse solution GUI, we get the prompts to resolve these with target environment connections, and new environment variable values. We don’t get this when using the Power Platform CLI, or GitHub Actions. So, to resolve these, we must use a deployment settings file. We can control the use of this with the following two inputs.

First we have this input to determine whether we are using a deployment settings file or not…

use-deployment-settings-file:

This input takes a true or false value. Then we have the input where we can provide the deployment settings file.

deployment-settings-file:

Want some more guidance on using this input with a deployment settings file to resolve connection references and update environment variables? Check out the following post which goes over this in more detail 🙂

Maximum wait time

By default, solutions have a maximum wait time of 60 minutes to import before they timeout and the process doesn’t continue. You can use the following input to specify the amount of minutes that a solution should have to import before this happens.

max-async-wait-time:

Import as managed

Finally we have the option to convert an unmanaged solution to a managed solution in case we didn’t do this during export, or for cases where perhaps we want to export an unmanaged solution, commit it to a repository, and then not have to export the solution again to import it as managed. To convert an unmanaged solution to managed during import, simply provide a true value for the following input.

convert-to-managed:

Upcoming content 📝

So! That’s a wrap on this post, thanks for dropping by to learn something new 🙂

There’s loads more upcoming content in this series on the Power Platform Developer Tools, so stay tuned by subscribing to my blog and don’t miss a thing! 📩

Subscribe
Written by
Lewis Baybutt
Microsoft Business Applications MVP • Power Platform Consultant • Blogger • Community Contributor • #CommunityRocks • #SharingIsCaring
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to LewisDoesDev.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.