3

We have a repo for a managed package, that we build through a dev hub/scratch org.

2 of the 3 developers, everything works as documented with the sfdx tutorials. 1 of the developers environment has an anomaly that we can not detect. Whenever we do sfdx force:source:push -u scratch-org-user we get errors, that are triggered because the dependent objects are not being passed to the scratch org appropriately. Further digging we found that the meta data being passed with the push seems to be incorrect. Even when we pull down the meta data from the partner org, and convert into the scratch org fresh, and push, it still creates the same issue, for example:

When you do a mdapi:retrieve, then a mdapi:convert, the package.xml all look correct, but when force:source:push is called, everything in the package becomes a "CustomSite", I've attached the converted output...

=== Converted Source

STATE FULL NAME TYPE PROJECT PATH

  1. Add ModelStatus CustomSite ..classes/ModelStatus.cls-meta.xml
  2. Add ModelStatus CustomSite ..classes/ModelStatus.cls
  3. Add wut CustomSite ..contentassets/wut.asset-meta.xml
  4. Add wut CustomSite ..contentassets/wut.asset
  5. Add Account_Page CustomSite .flexipages/Account_Page.flexipage-meta.xml
  6. Add Model_Page CustomSite ..flexipages/Model_Page.flexipage-meta.xml
  7. Add Opportunity_Page CustomSite ..flexipages/Opportunity_Page.flexipage-meta.xml

From a package.xml that looks similar to this (modified for privacy,security,etc):

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>deploy</fullName>
    <types>
        <members>ModelStatus</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>Model_Status</members>
        <name>AuraDefinitionBundle</name>
    </types>
    <types>
        <members>wut</members>
        <name>ContentAsset</name>
    </types>
    <types>
        <members>Account.Account_Tier__c</members>
        <members>Account.Active__c</members>
        <members>Model__c.End_Date__c</members>
        <members>Model__c.Model_Type__c</members>
        <members>Model__c.Start_Date__c</members>
        <members>Model__c.Status__c</members>
        <members>settings__c.name__c</members>
        <members>settings__c.value__c</members>
        <name>CustomField</name>
    </types>
    <version>43.0</version>
</Package>

The errors we get are errors you would see if a referenced class or asset wasn't present and could not be located.

The ironic thing, is using the exact same steps on a different users machine, from repo pull, to sfdx force:source:push, and the outcomes are totally different. 1 works, and 1 fails.

Thoughts?

  • Anyone? I'm desperate! ;-) – sol Jul 10 '18 at 3:36
  • Hmm, has the user whose machine is failing got any unusual/different entries in a .forceignore file or anything like that? Are both machines on the same version of the sfdx cli? – TomB Jul 10 '18 at 9:24
  • No files in the forceignore other than package.xml -- yes on versions too. We have tried the npm install version and the download from salesforce version, both deliver same error/result. We installed a VM (virtualbox, ubuntu) and ran through our same steps, and it worked fine. So pretty sure its something environmental, just dont know what. :( – sol Jul 10 '18 at 20:24
  • Ok, after further debugging... it still doesn't work, however, more info... I formatted the machine, cleared the entire environment, and installed just the necessary tools to run sfdx. Still errors. Downloaded dream house, tried to push to scratch org... same error. – sol Jul 13 '18 at 19:01
  • The machine(s) that it works with, are there any uncommitted (to Git) files or unpushed (to the remote) commits in their project? Alternatively are there any unpulled files sitting in the scratch orgs of the working ones? If you've gone to the lengths of reformatting a machine, and the error is coming as a response out of the scratch org itself, then I suspect that there are files missing from the project somewhere, or possibly a managed package that has been installed on the scratch orgs that work, and that is a dependency of your package? – TomB Jul 16 '18 at 8:29
2

After many months of racking my brain, formatting my machine, trying new profiles, etc, and ultimately moving to windows to do my SFDX work, I figured out this problem.

When I create projects, I do so in a folder structure beginning with ~/sites/. Moving the repo to a different folder name, like ~/code/ allowed everything to work appropriately.

Best guess to the cause was the the packaging api with SFDX evaluates the entire path of each file to assess its destination in the scratch org. when it saw sites in the path, it assumed everything beneath it was a CustomSite and therefore all of the validations failed. :(

Easy fix, but good heavens, nigh impossible to find. @sfdx team, hopefully you see this and can add some documentation/error checking. My guess is that the same problem would occur with other reserved paths like classes, aura, objects, staticresources, etc.

  • The SFDX team are pretty active on the Success Community and on Twitter; you may be able to get their attention there with this really interesting issue. – David Reed Oct 23 '18 at 23:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.