Ability to see debug logs of force:package:version:create

[rnavroze]

Is your feature request related to a problem? Please describe.
I have run into an obscure bug in SFDX Package Creation where a particular test is failing only on package version create, but building the package without --codecoverage works fine and then on deploying to a test scratch org, all tests pass. Unfortunately, a package without --codecoverage cannot be promoted. This test works fine in scratch orgs with multiple configurations (Person accounts on/off, multicurrency on/off). Unfortunately, I cannot see the debug logs of a package creation process so I don't know what is triggering the error. Weirdly enough, another test which does the same thing passes the test on package create.

What are you trying to do
Package version create failing tests, same tests pass in all other circumstances.

Describe the solution you'd like
The ability to see a full debug log of force:package:verison:create to better understand why the process is failing.

Describe alternatives you've considered
Removing the test solves the problem but leaves us with uncovered code. Adding --loglevel=TRACE does not show debug logs.

Additional context
Add any other context or screenshots about the feature request here.

[wmigas]

I like this idea, but without changing tooling API by salesforce it cannot be added to the sfdx cli. sfdx just create Package2VersionCreateRequest and then polling to check status. If status equals Error then it returns data from the Package2VersionCreateRequestError object

[VivekMChawla]

@rnavroze - What you're experiencing might be something that the "Unpackaged Metadata" pilot could help with.

https://releasenotes.docs.salesforce.com/en-us/winter21/release-notes/rn_sfdx_packaging_path_unpackaged_md.htm

As for the feature request for log visibility on package:version:create, I'd recommend reposting your suggestion in one of the packaging-related community groups for better visibility to the packaging team.

• Managed Packaging (Partner Community)
• Unlocked Packaging (Trailblazer Community)

I'll mention this to the PM as well.

[rnavroze]

@VivekMChawla Thank you for the suggestion. I eventually figured out through a lot of trial and error that it was a race condition where a record being created by a trigger was being deleted by the test, which worked fine in all environments but somehow not the package build environment.

I will post the suggestions there as well as this is certainly a useful feature for situations like this.

[github-actions[bot]]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[github-actions[bot]]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[vishesh04]

I worked around this by creating a new scratch org, not change any setting in the org and run tests against this org

[gsbasso]

We've run into numerous examples of this behaviour (tests only fail when creating a new package version).

Typically the failures seem to be a result of a test running in a package that is not aware of content from a package it depends on.

For example, let's say you have Packages A and B, with B depending on A. In Package A you have defined some additional Task status values, some of which indicate the task is closed. If you have a test in Package B that sets the status of a Task to one of these additional closed values and then query based on IsClosed, you will not get a result because in the context of the test in Package B the additional status values do not exist. A similar behaviour happens with custom permissions.

We have even developed an isRunningCodeCoverageTest static method that we use to ensure certain asserts pass (or to bypass certain asserts). The method checks if the email of the current user is [email protected].