-
Notifications
You must be signed in to change notification settings - Fork 41
1.1 Useful Tips and Tricks
If sf.env
is defined, it will be used in conjunction with ~/solenopsis.properties
to define your setup and allow you to utilize different orgs, source tree setup, etc. If you define something in ~/solenopsis.properties
it can be overridden with the property file found for sf.env
- this includes setting a new value or removing one. The value of sf.env
will attempt to load a properties file from ~/${solenopsis.user.home}/environments/${sf.env}.properties
. No errors arise if this property file is not found.
solensopsis -e [environment]...
bsolenopsis -Dsf.env=[environment]...
ant -Dsf.env=[environment]...
If find that you cannot pull completely from an environment due to size constraints (Issue #18), you may want to use selective-pull
or selective-pull-to-master
. If you do not specify the types to pull, all non-folder based types will be pulled. However, if you do specify the types then only those types will be pulled for you. For env
below, please use one of the ones denoted in your solenopsis.env.credentials.HOME
.
tbd
ant -f /usr/share/solenopsis/ant/solenopsis.xml -Dsf.env.DEPENDENT=[env] selective-pull
ant -f /usr/share/solenopsis/ant/solenopsis.xml -Dsf.env.DEPENDENT=[env] -Dsf.types=[Comma Separated Types] selective-pull
Pull all triggers and classes:
bsolenopsis -Dsf.env.DEPENDENT=[env] -Dsf.types=ApexClass,ApexTrigger selective-pull
bsolenopsis -Dsf.env.DEPENDENT=[env] selective-pull
bsolenopsis -Dsf.env.DEPENDENT=[env] -Dsf.types=[Comma Separated Types] selective-pull
Pull all triggers and classes:
bsolenopsis -Dsf.env.DEPENDENT=[env] -Dsf.types=ApexClass,ApexTrigger selective-pull
The property sf.batchSize
denotes the number of objects to retrieve in a batch. If not set, the default value is 300. However, you can tune by adjusting the value of this property to meet your needs.
If you want to see what Solenopsis is building yet not deploye, use the sf.dryRun system property. Essentially Solenopsis will process normally up to but excluding deployment.
tbd
ant -f /usr/share/solenopsis/ant/solenopsis.xml -Dsf.dryRun=[any value] [some operation]
Destructive push:
ant -f /usr/share/solenopsis/ant/solenopsis.xml -Dsf.dryRun=true destructive-push
bsolenopsis -Dsf.dryRun=[any value] [some operation]
Push:
bsolenopsis -Dsf.dryRun=true push
If you find that you timeout deploying and running all tests, it is very easy to reconnect to those tests as follows below. Please note REQUESTID
represents the async Id that Salesforce returns when deploying. For example:
[sf:deploy] Request Id for the current deploy task: 04sZ0000001640oIAA
The REQUESTID
is 04sZ0000001640oIAA
.
solenopsis --requestid [REQUESTID] run-tests
ant -f /usr/share/solenopsis/ant/solenopsis.xml -Dsf.asyncRequestId=[REQUESTID] run-tests
bsolenopsis -Dsf.asyncRequestId=[REQUESTID] run-tests
The following are all the log type strings one can use when running tests:
- None
- Debugonly
- Db
- Profiling
- Callout
- Detail
This can be set via Ant -Dsf.logType
or Python --logtype
command line options.
ant -Dsf.logType="Debugonly" -f /usr/share/solenopsis/ant/solenopsis.xml run-tests
solenopsis --logtype Debugonly run-tests
bsolenopsis -Dsf.logType="Debugonly" run-tests
If you need to run tests in an environment that may not exist in your master environment, you can selectively pull the tests from an environment and then run those. For env
below, please use one of the ones denoted in your solenopsis.env.credentials.HOME
.
tbd
ant -f /usr/share/solenopsis/ant/solenopsis.xml -Dsf.env.DEPENDENT=[env] -Dsf.env.master=[env] -Dsf.types=ApexClass -Dsf.generateTests=true selective-pull run-tests
bsolenopsis -Dsf.env.DEPENDENT=[env] -Dsf.env.master=[env] -Dsf.types=ApexClass -Dsf.generateTests=true selective-pull run-tests
Sometimes you may encounter the need to apply changes to files upon deploy or pulling. To do so, simply provide XSLTs and include them in a directory structure similar to your source tree. In your ~/solenopsis.properties file - or from command line - define an sf.xsltDir
property that is a "root" directory containing XSLTs where each XSL is defined in a corresponding directory as that in your source -and- has the same "base name" as the file with an ".xsl" extension. For example, assume you need to do some form of processing of Admin.profile and that the source exists in /foo/bar/alpha/src (it contains amongst other things the profiles subdirectory):
- /foo/bar/alpha/src/profiles/Admin.profile
- /foo/theta/xslts/profiles/Admin.xsl
- sf.xslDir = /foo/theta/xslts
tbd
ant -f /usr/share/solenopsis/ant/solenopsis.xml -Dsf.env.DEPENDENT=[env] -Dsf.env.master=[env] -Dsf.xslDir=[root xsl dir] [push or pull targets]
bsolenopsis -Dsf.env.DEPENDENT=[env] -Dsf.env.master=[env] -Dsf.xslDir=[root xsl dir] [push or pull targets]