Unanswered

Power Apps Portals CLI upload record failed does not exist

(1) Share

Report

Posted on by m3ngi3

725

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 😊

Categories:

Power Apps portals

I have the same question (0)

All responses (4)

Answers (1)

Christian Leverenz 1,214 on at

Like (1)

Report

@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

Was this reply helpful? Yes No
m3ngi3 725 on at

Like (0)

Report

@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 😁

Was this reply helpful? Yes No
Christian Leverenz 1,214 on at

Like (1)

Report

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

Was this reply helpful? Yes No
Verified answer

m3ngi3 725 on at

Like (2)

Report
So here is what I think I found:
DevOps seems to download the Git repo locally to the VM that runs the pipeline.
In my case this means that the manifest of a previous export is available for the Pipeline.
The Power Platform Build Tool seems to compare the old manifest of previous exports to the current Portal tables.
Then it records changes (like deleted records) to the new manifest of the new export.
Then a new import will give these failed notifications
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
Clean up the "old" manifest of the GIT manually for every GUID in the failed notification run
(verify that the rest of Portal Config files do not reference these GUIDs)
Run a new Export --> I saw that the Pipeline now did not update the manifest because there was nothing (no deleted records in old manifest) to compare it to
Run a new Import --> no Failed lines notifications

Was this reply helpful? Yes No