I have a Salesforce CI newbie issue. I'm trying to build a CI pipeline for Salesforce using Bitbucket / Jenkins and the Salesforce Migration tool. I'm trying to prototype the pipeline against a dev org using a source dump from sandbox which contains a number of licensed packages ( many of which are integrated into standard objects such as Account ). I'm encountering ( understandably enough ) the following error - "Only components in the same namespace as the organization can be created through the API" Is there a best practice to deal with issues such as this ? Do I need to download and deploy all licensed managed packages ?


You have to either remove the managed package items, or install the managed packages. You can use InstalledPackage to help automate the process if you want to go down the path of installing dependencies, or you can install them manually; Developer Edition orgs, like Sandbox orgs, can install any package and get an unlimited Site license for evaluation purposes. If installing is not suitable for your purposes, you'll want to come up with a way to strip any references to those packages from your code and metadata, which may be easier said than done.

  • I'll try your suggestion re. InstalledPackage. We really do need this to be fully automated. Thanks ! – DTek Nov 8 '16 at 0:59

I think your problem is that when you're retrieving from the sandbox you're retrieving using a non-specific package.xml file. As a result, when you retrieve the Account object, you get everything on Account including custom fields with namespaces from those installed packages. When you take that metadata and deploy to another org, it's trying to create fields that are in a namespace you don't own hence the error. You can get around this in one of two ways:

  1. Use an Unmanaged Package in your Sandbox org to select the metadata you want to retrieve. Go to Setup -> Create -> Packages and create a package. You won't ever distribute this package from here, but a package is a useful container that you can add your custom metadata into. Once you've added the metadata you want into the package, use the packageNames argument to the sf:retrieve call in your Ant targets. Set the value of packageNames to the package you created in the org. With this retrieve mode, you don't provide a package.xml file. The retrieve returns only the metadata in the package.

  2. Manually create a specific package.xml file for what you want. For example, don't retrieve the whole Account CustomObject in your package.xml file. Instead, just retrieve the CustomFields you want. I'd recommend option 1 as this can get painful to maintain.

If your custom metadata references fields or other metadata from any of the installed packages, you'll still need to use InstalledPackage to automate the installation in your build scripts.

FWIW, I spent the last 3 years building out our CI process around Ant + Force.com Migration tool, Jenkins and Github. From my experience, Ant can become a burden with more complex build automation logic like handling dependencies. It's possible and I built CumulusCI around Ant which I've been running for the last 3 years. That inspired me to spend the last 6 months rewriting it all in Python as CumulusCI 2.0 version that's in alpha now. Feel free to poke around for ideas for your scripts.

  • Thanks for the feedback; however I realized that wasn't my problem. I was able to resolve it by using installedPackage as suggested by sdfcfox. I'm facing a different issue while trying to install ( using the api ) npsp 3.0. This is what I see . – DTek Nov 18 '16 at 22:14
  • All Component Failures: 1. installedPackages/npsp.installedPackage -- Error: (Contacts & Organizations 3.4) A required package is missing, Details: Package "Contacts & Organizations", Version 3.4 or later must be install\ ed first. – DTek Nov 18 '16 at 22:15

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.