We are using the Portals support for Power Platform CLI - Power Apps | Microsoft Docs in an Azure DevOps Pipeline and after a few successful runs uploading the portal to a TEST Environment from our Git Repo (exported from a DEV environment) with a command like:
pac paportal upload --path $(System.DefaultWorkingDirectory)\ExportedPortal\custom-portal --deploymentProfile ${{ parameters.environment }}
at the end of the upload to TEST it gives this notification:
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to adx_entitylist With Id = c86f059d-4f36-ec11-8c64-000d3a2fd376 Does Not Exist
Started uploading website data
Loading Portal Manifest...
Manifest loaded successfully.
Connected to...Kiwa Dynamics 365 Inspection Portal TST01
Upload completed for table: adx_entityformmetadata
Upload completed for table: adx_website
...etc...
Upload completed for table: adx_publishingstate
Upload completed for table: adx_contentsnippet
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to adx_entitylist With Id = c86f059d-4f36-ec11-8c64-000d3a2fd376 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = c77a069a-bc3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = be45cb46-be3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to adx_entitylist With Id = c86f059d-4f36-ec11-8c64-000d3a2fd376 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = c77a069a-bc3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = be45cb46-be3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to adx_entitylist With Id = c86f059d-4f36-ec11-8c64-000d3a2fd376 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = c77a069a-bc3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = be45cb46-be3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to adx_entitylist With Id = c86f059d-4f36-ec11-8c64-000d3a2fd376 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = c77a069a-bc3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Updating table with record id:00000000-0000-0000-0000-000000000000 FAILED due to Adx_webpageaccesscontrolrule With Id = be45cb46-be3b-ec11-b6e5-000d3aab4dc4 Does Not Exist
Upload completed for table: annotation
Finishing: Import portal config
This is totally understandable, because these specific records were deleted from DEV environment so they are not needed in TEST. The manifest.yml file of the exported portal configuration files from DEV even know this:
- RecordId: c86f059d-4f36-ec11-8c64-000d3a2fd376
DisplayName: Assets
CheckSum: 5fe5fd7ea32d16be060ee2289163c1adace50e7b814217434a779a9a72d98f93
IsDeleted: true
...but if the manifest from DEV already states that the record has the property of IsDeleted: true --> why does the pac paportal upload command for TEST try to upload that record?
Should the tooling not be smart enough to skip this and prevent the (multiple) failed-notifications?
Just wondering if there is something I am missing here 😊
Solved! Go to Solution.
So here is what I think I found:
Again: no harm seems te be done except for these useless Failed notifications that cannot even be considered as traditional errors (where something actually went wrong).
My workaround
@Django ,
just to make sure: does this also happen, when do it manually from a clientmaschine?
In our company we also think, that some things are missing in that tool. For example the deletion of all files when using "-o true" on download is not that helpful when using git...
We are currently working on a devops integration for that and try to download the code from the targetsystem before uploading the new version (yes, call me paranoid). In that scenario you face problems in the devops (which is currently related to my limited experience in devops...) because you might overwrite your local new code with the one from the target. So we should create a branch before downloading or just upload to a completely diffrent repository for backup purposes. Just writing about it seems to me as there is not a clear way how to do it rightly 🙂
Have fun and thanks for publishing, that obviously also other people struggle with parts of the portals devops integration 🙂
Christian
@chleverenz --> not checked if also on Client from Visual Studio occurs.
In our case the Pipeline is a given fact so it needs to be fixed there.
I am also curious though so will update when I have tested this 😁
Hi @Django ,
does not help, but my commandline just told me:
so, seems to be a tool problem and not a problem ob devops...
Kind regards, Christian
So here is what I think I found:
Again: no harm seems te be done except for these useless Failed notifications that cannot even be considered as traditional errors (where something actually went wrong).
My workaround