Closed cjbadger closed 2 years ago
I actually came here to raise this exact issue and saw this. This occurs using either classic or yaml deployment jobs - noted above was classic.. we use pure yaml deployment jobs and are experiencing the same. The old MS tasks used to log errors properly to the deployment logs.. as do the wael hamze tasks it would be lovely to not have to go into the unified interface to view the import logs
@cjbadger @cT-m00cat @lar-mar same conclusion as in the correctly duped #232:
we've discovered, and now fixed, 2 somewhat independent issues:
pac solution pack
, or the "Pack Solution' PP-BT tasks, any PowerFX .yaml file was not detected, and consequently missing from the repackaged solution.zip. On import, this would cause the now-correct error message of a missing dependencyBoth of these issues have been fixed with the latest October refresh of pac CLI (version >= 1.20.3) and PP-BT (version >= 2.0.10). If this still reproes, please do open a new issue here with repro info and log file fragment/screenshots
PP Build Tools have been updated today.
As the release does not mention the new pac CLI version I guess we have to wait for the next update.
@lar-mar pac CLI has been updated to 1.20.3 as part of the 2.0.10 PP-BT refresh, but I neglected to mention it in the PP-BT release notes, sorry
@davidjenni Thanks for the feedback.
@davidjenni
I guess the issue still persists:
When checking the solution history in the environment I can see more details regarding the import:
It does still exist and this issue should NOT be closed. they have closed it and confused this with the other problem noted above - however the simple fact is that the logs in the task are rubbish, it's a regression in terms of usability and having to view solution imports in the environment to view logs of a PIPELINE solution import is just stupid. The previous versions LOGGED ALL OF THE INFORMATION TO THE PIPELINE LOGS AND THIS IS THE FUNCTIONALITY PEOPLE ARE ASKING FOR
@davidjenni I think you have misunderstood the main point of the issue MOST of us are reporting as a problem for us and you have fixed these two issues:
_when packaging a locally unpacked solution via pac solution pack, or the "Pack Solution' PP-BT tasks, any PowerFX .yaml file was not detected, and consequently missing from the repackaged solution.zip. On import, this would cause the now-correct error message of a missing dependency
the "given key was not present in the dictionary" was a status code returned from the Dataverse import API that the pac CLI couldn't decode._
THIS DOES NOT ADDRESS THE TOTAL LACK OF ERROR LOGGING
Expected behaviour: The deployment will fail, and the message for the exception that caused the task to fail (in this case, a 'Missing Dependencies' message) should be captured in the deployment job's logfile for that task (as downloaded after completion of the job via the 'Download all logs' button in the deployment), and should be presented as an error-level log in the deployment logs UI. To confirm the message that is expected to be captured in the logfiles, and presented in the deployment logs UI, go to make.powerapps.com, select the target environment, then go to Solutions > History, click the failed import job, and see the 'Exception Message' (this is also the workaround that is necessary in order to determine what actually caused the task to fail and remedy it).
For example:
Solution manifest import: FAILURE: The following solution cannot be imported: ConsensusApps. Some dependencies are missing. The missing dependencies are : <MissingDependencies><MissingDependency><Required type="90" schemaName="BHScheduler.CRM.Workflows.RunCurrentSchedules, BHScheduler.CRM, Version=1.0.0.0, Culture=neutral, PublicKeyToken=34c867ff4a3b575a" displayName="BHScheduler.CRM.Workflows.RunCurrentSchedules" solution="Active" id="{REDACTED-GUID}" /><Dependent type="29" displayName="CR | WF001 | Process Schedules" id="{REDACTED-GUID}" /></MissingDependency><MissingDependency><Required type="connectionreference" displayName="bhlabs_sharedcommondataserviceforapps_4cd1d" solution="Active" id.connectionreferencelogicalname="bhlabs_sharedcommondataserviceforapps_4cd1d" /><Dependent type="29" displayName="CR | PA001 | Schedule Runner" id="{REDACTED-GUID}" /></MissingDependency></MissingDependencies> , ProductUpdatesOnly : False
Actual behaviour: The deployment fails, but the message for the exception that caused the task to fail is not captured in the deployment job's logs for that task at all, and is not presented in the deployment logs UI at all (as an error-level log, or otherwise). Instead, the following message is displayed (as an information-level log):
Error: The given key was not present in the dictionary.
THIS IS NOT RAISING AN ISSUE AROUND THE CONTENT OF THE ABOVE ERRORS.. I AM NOT ASKING TO LOOK AT THE "The given key was not present" error. I want the same level of logging as the previous tasks and TO NOT HAVE TO go to make.powerapps.com, select the target environment, then go to Solutions > History, click the failed import job, and see the 'Exception Message' - I need to see these messages in the pipeline output.
Hi @lar-mar,
Do you able to find the resolution for this issue? Do we need to use earlier version of the PP-BT tasks?
Hi there,
I've noticed that in the last few weeks - possibly since the September Refresh release, or v 2.* of the Build Tools - there seems to have been a regression in the error logging for the 'Power Platform Import Solution' task. This has been observed in several ADO Services Classic Release Pipelines.
To reproduce:
See (attached) the deployment logs for this task (18_Power Platform Import Solution (Apps).log, with redactions.
I've seen this incidentally raised in comments by other users in community forums, and in other issues in this repo. See, for example:
Note: the levels at which messages are logged in the deployment logs often does not match the level one would expect the message to be, but this is a separate issue, and one which I think pre-dates the present issue. For example: messages that are obviously information-level messages are captured as errors (eg
2022-11-09T20:26:56.9884955Z ##[error]failed: Connected to...QA
is obviously not an error, but is reported as such).Please let me know if any further details would be helpful.
Thanks!
Chris.