I've been trying to set up continuous integration between dev (developers' personal dev sandbox) - dev integration box using Jenkins. It works well when dealing with classes, VF pages and triggers.But I am trying to setup a true CI for the whole org (except for things not supported by ant ofcourse), but I haven't been successful when it comes to compnents like objects, workflows, entitlement processes into the CI solution. I faced several issues such as : If I have an object for which there is no workflow defined yet, and my src contains an empty meta-data file for workflow, it attempted to deploy this empty workflow file as well and reported error that recipient is missing(some thing similar). One of the root causes is that is is not able to identify that there is no change in a file between source and destination.

Is there a way to configure CI so that it ignores any file that isn't different from the one present in destination target.

  • 1
    In our Jenkins CI we take the approach that the content of our version control system should always be deployable to an empty org. So checking in something (and its reference in package.xml) that relies on other work not yet checked in breaks the build and the individual concerned is blamed for that. So in my experience - perhaps you have some reason to be different - the standard Ant tools are sufficient.
    – Keith C
    Aug 11 '14 at 20:20
  • There are a number of ways a deployment can fail and knowing the specific errors would help a lot. @KeithC is absolutely right that the code in your repository should be deployable into an empty org. Could you give us an example of the exact error message you get when the deployment fails due to the empty file? Aug 11 '14 at 21:41

"recipient is missing" usually means that SF tries to find an user referenced in the workflow/email alert/approval process with matching email/username and complains when it can't find one. It used to be totally dumb (requiring some kind of preprocessing of the file before actual commit or upload attempt... messy but then it makes you work in branches in your source control system which and commit consciously which isn't a bad idea).

They recently improved it but still it'll go nuts if the target user can't be found or is inactive in target org. (Or if it's very first email alert for example it'll force you to setup a default workflow user I think - and in that area deployment via API isn't as smart as trying to do it manually in the target org, it won't suggest this problem).

I'm not sure you can do much in Jenkins... but if you are sure that given file should be skipped this time you could ignore it. Either in SVN/Git/tool of your choice or by excluding it from package.xml...

Sadly this might mean you need to somehow dynamically create package.xml from changed files every time. It's not impossible but it's painful and error-prone:

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.