https://github.com/rpothin/PowerPlatform-ALM-With-GitHub-Template-Demo/runs/6928921726?check_suite_focus=true

Currently, the ALM strategy proposed in this template repository considered "basically" only one solution.

You can duplicate workflows to manage multiple solutions separately, but I am not sure it is the best way to do it.

With this issue we will try to explore some ways to improve the situation regarding this requirement.

During some tests (ex: 5-import-solution-to-validation #103) I have encountered the following unexpected error in the solution pack step:
Error: Invalid format for element 'Version'; Should be 'x.x.x.x' where x is an integer.

After some investigations, by manually updating the solution version in the Power Apps maker portal, I found that solution versioning model (major.minor.yyyymmddxxx with xxx the github.run_number predefined variable) proposed in this repository reached some limits:

• 1.0.20220508103 ==> Error
• 1.0.2022050899 ==> Ok
• 1.0.20220508100 ==> Error

To avoid this kind of errors, and providing a better scalability for the model proposed in this repository, I propose a new versioning model: major.yyyymmdd.xxx with xxx the github.run_number

The ALM strategy proposed in the template repository involved (at least today 😊) the creation of different environments (development and build).

Currently, the configuration details required by the create-environment action are managed in GitHub secrets.

I think this way of managing this kind of information (not really confidential) is a little bit "overkilled".

I would like to manage these configuration details in a file that would be used in the different workflows where we create an environment.

The idea would be to consider different Azure Applications Insights for the canvas apps through different environments (at least one for production and one for non-production work).

Idea: It seems in the unpacked canvas app there is a "AppInsightsKey.json" file that contains the instrumentation key. We could set the value to "00000000-0000-0000-0000-000000000000" during the export and then update it again before the pack step for the import of the solution based on values in the "CustomDeploymentSettings_%.json" files.

Microsoft documentation: https://docs.microsoft.com/en-us/power-apps/maker/canvas-apps/application-insights

We currently have 31 code scanning alerts regarding our PowerShell scripts - nothing too serious but if we want to have a good code quality in this repository, we definitely need to work on that.

The environment variables below from the solution-quality-check-on-pr workflow should be moved to the configurations.json file.

solution_checker_result_output_directory:  solutionchecker/ # Output folder for the results of the solution checker execution
solution_checker_geography: Canada # Considered geography for the solution checker execution (https://docs.microsoft.com/en-us/power-platform/alm/checker-api/overview#determine-a-geography)
solution_checker_max_nb_medium_severity_points: 5 # Maximum number of the Medium severity points that will be tolerate in the solution checker results
solution_checker_max_nb_high_severity_points: 0 # Maximum number of the High severity points that will be tolerate in the solution checker results

Currently this workflow triggers on pull requests targeting the main branch without path restrictions.
But because the goal of this repository is to work on Power Platform development (not on the GitHub workflows inside this repository for example) we should definitely consider adding some path filtering in the tigger of this worklow.

For example, in the import-solution-to-validation workflow we have the following trigger:

on:
  push:
    branches: [ main ]
    paths:
      - 'Solutions/**'
      - '!.github/**'
      - '!Scripts/**'
      - '!Configurations/**'
      - '!.all-contributorsrc'
      - '!CHANGELOG.md'
      - '!CODE_OF_CONDUCT.md'
      - '!CONTRIBUTING.md'
      - '!LICENSE'
      - '!README.md'

https://github.com/rpothin/PowerPlatform-ALM-With-GitHub-Template/actions/runs/2432404910

"CodeQL Action v1 will be deprecated on December 7th, 2022. Please upgrade to v2. For more information, see https://github.blog/changelog/2022-04-27-code-scanning-deprecation-of-codeql-action-v1/"

Based on information seen in an issue from the CoE Starter Kit - [ALM Accelerator - Feature]: Remove flow json formatting from pipelines GitHub repository and also some tests, it seems the "out-of-the-box" GitHub actions for the export and import of solutions natively handled cloud flows JSON formatting now.

The goal of this issue is to remove the custom code in the workflows to manage the JSON formatting of cloud flows after solution export and before solution import.

https://docs.github.com/en/actions/using-jobs/using-concurrency

Workflows that could benefit from this feature:

• Workspace initialization (for the same issue)
• Deployment of solution to validation or production

• New Dependabot configuration file
• Language display name configuration differences based on Dataverse environment creation method ("English" for the out-of-the-box GitHub action vs "English (United States)" for the custom PowerShell function)

During the cleaning of the test data (solution content) in the repository made in the v0.2.0 we forgot to delete the configuration folder associated to the solution.

To remediate to this issue, we will need to cover the points below:

• Add a section in the README about the configuration files for the solutions
• Remove the "Configuration/PowerPlatformALMWithGitHub" folder

Currently, our cloud flows activation process, based on the Enable-CloudFlows.ps1 PowerShell script is not built to handle correctly scenarios with child flows.
Child flows need to be enabled before the cloud flows that use them, and if you try to enable a cloud flow depending on a disabled child flow you will get an error that will stop the GitHub workflow with a failed status.

We need to find a way to make this process more reliable.

Resources:

• [ALM Accelerator - BUG]: Activate Flows for Connection References Fails for "Child" Cloud Flows #2449
• Invoke-ActivateFlows

There is a convert-to-managed available in the import-solution but I don't find lot of information about this option.

We will to try it to see if it can bring some value to our repository (like give the option to directly convert an unmanaged solution to a managed solution without going through a just in time build environment).

Currently, after the creation of the development environment in the workspace-initialization workflow we create a team on the environment to give access to the developers as System Administrators.

But, in the case of Dynamics 365 environments, if we don't limit access to a specific security group, everyone with a Dynamics 365 license will be created as user on the environment.

From a governance perspective I think we can do better. The goal of this issue will te be to restrict the access to an environment to a specific security group.

A few points we are thinking of covering in this issue:

• Remove the creation of release branches and only base the identification of version deployed to production using tags (created with GitHub releases)
• Integrate the creation of a GitHub release and deployment to the Production environment directly after the deployment to the Validation environment
  • Major version considered for the solution managed in a configuration file
  • Find a better way to automatically generate GitHub release body regarding what has been changed (idea Automatically generated release notes)
• Confirm that the same commit is used in the different jobs of a GitHub workflow for the deployment of a release candidate (should be ok based on the information in the page of the checkout action)

Bug Description

While importing a solution in the "solution-quality-checks" GitHub workflow, we get a timeout error on the "Import solution as unmanaged to build env" step.

Steps To Reproduce

Trigger a run of the "3-solution-quality-check-on-pr" GitHub workflow by creating a pull request or updating the source branch of a pull request.

Expected Behavior

The considered solution is imported without an error.

Relevant log output

Error: The request channel timed out while waiting for a reply after 00:01:59.9989995. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
      The request channel timed out while waiting for a reply after 00:01:59.9989995. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
          The HTTP request to 'https://gh-build-20220127-1***/XRMServices/2011/Organization.svc/web?SDKClientVersion=9.0.46.3291' has exceeded the allotted timeout of 00:02:00. The time allotted to this operation may have been a portion of a longer timeout.
              The operation has timed out

Code of Conduct

• I agree to follow this project's Code of Conduct

Using the import-as-holding input in the import-solution action and the upgrade-solution action we can now implement a solution upgrade strategy with GitHub workflows.

⚠It seems the "upgrade-solution" action is only available with "username / password" authentication for now.

• Following path to configuration file not valid: ./Configurations/PowerPlatformALMWithGitHub2/CustomDeploymentSettings_validation.json
• Cannot find path 'D:\a\PowerPlatform-ALM-With-GitHub-Template-Demo\PowerPlatform-ALM-With-GitHub-Template-Demo\Solutions\PowerPlatformALMWithGitHub2\CanvasApps' because it does not exist.

Example : https://github.com/rpothin/PowerPlatform-ALM-With-GitHub-Template/runs/6343294256?check_suite_focus=true

• export-and-unpack-solution / 2nd solution unpack step
• set-canvasapps-instrumentation-key / "manual" solution pack

Tests

• For the export-and-unpack-solution workflow, the folders with the source code of the canvas apps should be generated with only one solution unpack
• For the import-solution-to-validation using the set-canvasapps-instrumentation-key action, the configured Azure Application Insights Instrumentation Key should be considered without the "manual" solution pack step

Currently Power Platform developers can choose to use one of the 2 versions of the URL below to access the Power Apps maker portal:

• make.powerapps.com
• make.preview.powerapps.com

To bring some flexibility to the developers who would like to use this repository template, we will bring this base URL as a configuration.

The idea would be to replace "manual" calls to PAC CLI after the unpacking of a solution by the new input parameter in the out-of-the-box actions (solution unpack and pack).

Resources:

• unpack-solution
• pack-solution

Details regarding expected updates in the documentation (README...) related to the next version (0.3.0) will be added here later...

There are duplicate parts in the current workflows. The goal would be to replace these parts by reusable workflows stored in the same repository.

The parts to convert would be the ones below:

• #190
• #192
• #197

@all-contributors please add @rpothin for ideas, code, content, doc, maintenance, projectManagement and test

Depending on the requirements of the applications you build in a Dataverse environment and also the evolution of the platform itself, it could be interesting to manage the configuration of the Dataverse environments involved in the development process (dev, build, validation, production...) with code.

Scope of what we would like to cover in this issue:

• Languages
• Organization table
• DLP policy configuration (related issue to create to dynamically manage the short-lived development environments)
• Configuration data (like teams, business units...)

Currently, the "force-overwrite" input is set to "true" in "import-solution" action.
But it seems it does not allow us to take advantage of the "smart-diff" implementation done on the import process to make it faster.

I am not sure that adding a part of the trigger conditions of the workflow in the name is really great (we are missing the "in progress" tag condition).

It is why I think we could simplify the name of this workflow with something like: "workspace-initialization"

Currently, we consider only one developer (email provided in a GitHub secret) in the workspace-initialization-when-issue-assigned workflow.

The goal was to implement a solution to quickly give access to a user to the new development environment just created. But it was definitely more a POC than a final solution.

The next target is to consider the entire development team in this process. Because if another team member need to access the considered just in time development environment to check something or to provide some help, we would like to be sure to have everything correctly set up.

• Bump actions/download-artifact from 2 to 3
• Bump actions/upload-artifact from 2 to 3
• Bump peter-evans/create-or-update-comment from 1 to 2
• Bump peterjgrainger/action-create-branch from 2.0.1 to 2.2.0

Currently, in the solution-quality-checks job of the solution-quality-check-on-pr workflow we build a managed version of a solution using a just-in-time environment but without using the build-managed-solution reusable workflow.

The goal of this issue is to reorganize the solution-quality-check-on-pr workflow to use the build-managed-solution reusable workflow.

Requirements:

• The solution checker will be executed on the unamanged version of the solution generated in the build-managed-solution reusable workflow.
• The workflow needs to fail if at least one of the conditions below is not met:
  • Generation of the managed version of the solution without error
  • Solution checker pass the threshold specified in the configuration file

New inputs have been added to the export-solution - non-exhaustive list below:

• export-auto-numbering-settings
• export-calendar-settings
• export-customization-settings
• export-email-tracking-settings
• export-general-settings
• export-outlook-synchronization-settings
• export-relationship-roles

We should definitely try some of these new options at some point to see if it can bring some value to this repository.

2 inputs have been added to the import-solution action to manage deployment settings file: use-deployment-settings-file and deployment-settings-file

A deployment settings file can be created using the pac solution create-settings command (Microsoft Power Platform CLI - Solutions).

• #161
• #163
• #165

To continue our effort to centralize non-sensitive configurations to one file in the repository, we think it could be great to move the SKU for the Dataverse environments created (dev and build) from workflows in the global configuration file.

Bug Description

When we try to remove the Power Platform CLI source code from the local copy of the repository in the agent of a run of the "export-from-dev" GitHub workflow we get the following error: Access to the path 'D:\a\PowerPlatform-ALM-With-GitHub-Template-Demo\PowerPlatform-ALM-With-GitHub-Template-Demo\pac\Microsoft.PowerApps.CLI.***\tools\Microsoft.ApplicationInsights.dll' is denied.

Steps To Reproduce

Run the "2-export-and-unpack-solution" GitHub workflow with valid input parameters.

Expected Behavior

The considered solution is exported and unpacked without an error.

Relevant log output

Remove-Item: D:\a\_temp\1a633e5c-1bdc-4adf-82f6-0456590a19d6.ps1:23
Line |
  23 |  Remove-Item -Path $outFolder -Recurse
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Access to the path
     | 'D:\a\PowerPlatform-ALM-With-GitHub-Template-Demo\PowerPlatform-ALM-With-GitHub-Template-Demo\pac\Microsoft.PowerApps.CLI.***\tools\Microsoft.ApplicationInsights.dll' is denied.

Code of Conduct

• I agree to follow this project's Code of Conduct

Information: https://opensource.stackexchange.com/questions/6389/how-do-the-years-specified-in-a-copyright-statement-work#:~:text=In%20the%20case%20of%20open,publicly%20visible%20version%20control%20repository.

https://github.com/actions/checkout/tags

Currently we use a custom output configured in the create-build-environment job in different workflows of this repository for the domain name of the just in time build environment that we combine with other variables to generate the environment URL with use in other actions (like Import solution as unmanaged to build env).

It would be definitely better to use the environment-url output provided in the create-environment action.