kevinohara80 / dmc Goto Github PK

Currently, when retrieving reportType metadata, no files are found.

Bb: ~/projects/scorecard  (SC-3893) $ dmc retrieve src/reporttypes/* 
[dmc] using org: sc
[dmc] loaded .dmcignore
[dmc] matching types
[err] no files found for retrieve
[dmc] [NOT OK]

I'm attempting to create a login to a custom Salesforce domain using the following command:
dmc login -u https://custom-domain/... org1

However, when I issue that command the login redirect doesn't send me to that custom domain's login, instead it sends me to the standard Salesforce "https://login.salesforce.com/...". This will definitely authenticate me to the custom domain. Am I using the command incorrectly? When I do a "help" on that login command, it specifies that I can us the -u flag/option to point to the URL that I wish to use for authentication purposes.

-- Edit --
There is a "workaround" for this capability. When issuing the dmc login -u <custom URL> orgName command, your default browser will open a tab/window to the standard login.salesforce.com. You can modify the domain that is a part of that callout so that it points to the correct custom domain endpoint. You must leave, in place, the callback components (e.g. token, etc...) that are a part of that URL. However, if you modify the domain for that URL and then continue with the login process, the callback will register with the correct domain.

For businesses that use a proxy, allow a proxy to be specified to route all SF traffic through.

Actual

When the retrieve command is run, the retrieve will call the metadata api regardless of whether or not the glob patterns match actual metadata after the listMetadata call occurs

Expected

When the globs match no metadata, the retrieve should not occur and an error should be shown

Update 9/29/2016: I upgraded to DMC 1.2.3 and am having the same problem with this one org specifically. I have not experienced this with any other production or sandbox instances.

I am having an issue with my production org specifically, which is currently on Summer 16. My sandboxes, on Winter 17, are not experiencing this problem. I am using DMC 1.1.0 on Windows 10 in the standard command prompt.

If I do a dmc retrieve src/customMetadata/* or any glob pattern that matches this, I receive a response of [err] undefined: undefined

c:\%repodir%>dmc retrieve src/customMetadata/* [dmc] using org: myLogin (default) [dmc] loaded .dmcignore [dmc] matching types [dmc] * matched type: CustomMetadata [err] undefined: undefined [dmc] [NOT OK]

This occurs even though I have now specified this folder in my .dmcignore:
src/customMetadata/* src/customM*/* src/customM*

I have tried changing deploy_mode to 'metadata', I have tried several api_versions, with no change in results. I get a Salesforce System Error/gack when I try to do the same thing in MavensMate, so it must be some issue with Salesforce.

The best way I have found to retrieve all the rest of my metadata without this crashing my retrieve is by manually removing CustomMetadata from the dmc index.json file. This change is overwritten when I re-index, of course. I tried to build globbing patterns that would grab everything but this one folder, but haven't found a clean solution yet.

Here are some thoughts on how to work around a situation like this, not a DMC problem really

• Allow excluding specific metadata from being included in a retrieve at all, perhaps by using persistent attributes in the JSON index
• Do not even try to retrieve any metadata type that is excluded in .dmcignore
• See if there is any more information we could display in the case of a transaction failure like this

Does anyone have ideas on a better workaround than modifying the project index?

When you type dmc deploy with no glob arguments, it should assume that you want to deploy all of your metadata. Similar to doing dmc deploy src/**/*

I tried to run all test methods using dmc test -a --coverage -o myorg, but I got the following error:

[dmc] using org: myorg
[dmc] processing 145 records
/usr/local/lib/node_modules/dmc/commands/test.js:40
          var td = r.SymbolTable.tableDeclaration;
                                ^

TypeError: Cannot read property 'tableDeclaration' of null
    at /usr/local/lib/node_modules/dmc/commands/test.js:40:33
    at arrayMap (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:1406:25)
    at map (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:6710:14)
    at interceptor (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:12240:26)
    at thru (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:5927:26)
    at baseWrapperValue (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:2768:30)
    at LazyWrapper.lazyValue [as value] (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:1077:16)
    at baseWrapperValue (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:2761:25)
    at LodashWrapper.wrapperValue (/usr/local/lib/node_modules/dmc/node_modules/lodash/index.js:6124:14)
    at /usr/local/lib/node_modules/dmc/commands/test.js:65:10
    at Object.resolve (/usr/local/lib/node_modules/dmc/node_modules/nforce/lib/promises.js:25:20)
    at processResponse (/usr/local/lib/node_modules/dmc/node_modules/nforce/index.js:1020:25)
    at Request._callback (/usr/local/lib/node_modules/dmc/node_modules/nforce/index.js:1078:7)
    at Request.self.callback (/usr/local/lib/node_modules/dmc/node_modules/request/request.js:187:22)
    at emitTwo (events.js:100:13)
    at Request.emit (events.js:185:7)

Actual

When watching files in dmc and a save is triggered on a meta.xml file, the deploy fails

Expected

Saving a meta.xml file should deploy the corresponding metadata file.

Currently, doing a dmc retrieve for metadata will return all unpackaged, and packaged (namespaced) metadata that can be coming from managed packages. The default should be only organization-level metadata.

Metadata in subfolders doesn't retrieve because listMetadata calls require folder. This needs to be fixed.

When a token is auto-refreshed for an org that is a sandbox, it fails with the invalid_grant error message

I know documentation is hard to write, but after trying a bunch of things to login, I finally figured out that to log-in to a sandbox I should use:

dmc login -t "loginname"

which will use test.salesforce.com instead of login.salesforce.com to login.

When files are being copied from the tmp directory to the src directory, you get unlinking errors when the file tries to overwrite an existing copy. This seems to be some sort of a race condition where the directory is being unlinked after a file is being copied into that directory.

λ: dmc retrieve 'src/classes/TestUtil*'
[dmc] using org: l11.dev2 (default)
[dmc] matching types
[dmc] * matched type: ApexClass
[dmc] retrieve status: Pending
[dmc] unzipping to tmp dir: /Users/kevinohara/.dmc/.tmp
[dmc] extracting zip
[dmc] merging files to src
[dmc] * copying file: classes
[dmc] * copying file: classes/TestUtil.cls
[dmc] * copying file: classes/TestUtil.cls-meta.xml
[err] ENOENT, unlink '/Users/kevinohara/dev/l11/production/src/classes/TestUtil.cls'
[err] file copy errors
[err] [NOT OK]

Actual

Running a deploy on an Apex Class that triggers compile errors does not list the individual compiler errors

Expected

Individual compile errors should be logged in a human-friendly fashion

Example

dmc] using org: dev1 (default)
[dmc] searching for local metadata
[dmc] deploying 1 metadata files
[dmc] loading related metadata ids
[dmc] loaded 1 ids
[dmc] creating stub files
[dmc] created 0 stub files
[dmc] creating static resources
[dmc] deployed 0 static resources
[dmc] creating container
[dmc] [create]  metadata container: 1dcd0000000H9KqAAK
[dmc] [create]  container member: ApexClass::LeaderboardController
[dmc] Deploying...
[dmc] * deploy status: Queued
[dmc] * deploy status: Queued
[dmc] * deploy status: Queued
[dmc] * deploy status: Failed
[err] CompilerErrors
[dmc] [delete]  metadata container: 1dcd0000000H9KqAAK
[err] Compiler Errors
Error: Compiler Errors
    at /Users/kevinohara/dev/node/dmc/commands/deploy.js:211:25
    at /Users/kevinohara/dev/node/dmc/node_modules/nforce-tooling/index.js:193:26
    at Object.resolve (/Users/kevinohara/dev/node/dmc/node_modules/nforce/lib/promises.js:25:20)
    at processResponse (/Users/kevinohara/dev/node/dmc/node_modules/nforce/index.js:999:25)
    at Request._callback (/Users/kevinohara/dev/node/dmc/node_modules/nforce/index.js:1054:7)
    at Request.self.callback (/Users/kevinohara/dev/node/dmc/node_modules/nforce/node_modules/request/request.js:198:22)
    at Request.emit (events.js:110:17)
    at Request.<anonymous> (/Users/kevinohara/dev/node/dmc/node_modules/nforce/node_modules/request/request.js:1057:14)
    at Request.emit (events.js:129:20)
    at IncomingMessage.<anonymous> (/Users/kevinohara/dev/node/dmc/node_modules/nforce/node_modules/request/request.js:1003:12)
    at IncomingMessage.emit (events.js:129:20)
    at _stream_readable.js:908:16
    at process._tickCallback (node.js:355:11)
[err] [NOT OK]

I'm using DMC on my MS Windows 10, 64bit OS (also use it on my Mac...) and have been getting this error repeatedly whenever I issue a dmc watch src/{classes,pages}/* command and then modify a resource using my Atom editor. The terminal window shows that the deployment is "queued" then "completed". Then, the deletion of the metadata container, AND THEN another deploy is "queued" and finally "failed". I'm not sure what the final deployment would be as there is only one resource being modified. Ultimately the terminal window indicates that the deploy failed. However, when viewing the resource through either the "setup menu" access to that resource (e.g. a Apex Class or Visualforce Page) or the Developer Console tool, I can see that my changes were saved to the "org".

Could this be a problem with my DMC configuation or how I'm issuing the dmc watch ... command?

The console log always display unknown error occurred when compiling error.

[dmc] searching for local metadata
[dmc] deploying 1 metadata files
[dmc] deploy mode: dynamic
[dmc] deploy api: tooling
[dmc] loading related metadata ids
[dmc] loaded 1 ids
[dmc] creating stub files
[dmc] created 0 stub files
[dmc] creating static resources
[dmc] deployed 0 static resources
[dmc] creating container
[dmc] [create] metadata container: 1dc900000005SyRAAU
[dmc] [create] container member: ApexClass::test
[dmc] Deploying...
[dmc] * deploy status: Failed
[err] unknown error occurred
[dmc] [delete] metadata container: 1dc900000005SyRAAU

So can the tool display an error message's detail that will be better for debugging.

Currently when doing a dmc deploy of a new trigger, you receive a TableEnumOrId missing field error. This is a tooling api issue because the deploy works fine with the --meta flag. This happens during the stub file creation step.

Logs:

λ: dmc deploy
[dmc] using org: dev22 (default)
[dmc] searching for local metadata
[dmc] deploying 1 metadata files
[dmc] deploy mode: dynamic
[dmc] deploy api: tooling
[dmc] loading related metadata ids
[dmc] sfdc token refresh
[dmc] loaded 0 ids
[dmc] creating stub files
[dmc] [create] ApexTrigger::OpportunityTeamSync
[err] Missing field [TableEnumOrId] on trigger create
[err] unable to create stub files
[dmc] [NOT OK]

On a Windows machine the "dmc watch" command receives file changed events even when the file has not been changed. This seems to happen together with some other event, like file open in editor. This results in unnecessary deployments.

Our SF Code is located in several folders, one of which is called 'source', another of which is called 'systemtests'. It'd be great if dmc could support specifying source folders!
Currently, if you try and deploy a file that does not exist in the 'src' folder (which for us doesn't exist), you get

$ dmc deploy source/classes/Test1.cls
[dmc] using org: <orgname> (default)
[dmc] searching for local metadata
[dmc] deploying 1 metadata files
[err] unrecognized file path: source/classes/Test1.cls
[dmc] [NOT OK]

Symlinks don't seem to work, the file has to explicitly be in the 'src' folder:

$ dmc deploy src/classes/Test1.cls
[dmc] using org: <orgname> (default)
[dmc] searching for local metadata
[dmc] deploying 1 metadata files
[dmc] deploy mode: dynamic
[dmc] deploy api: tooling
[dmc] loading related metadata ids
[dmc] loaded 1 ids
[dmc] creating stub files
[dmc] created 0 stub files
[dmc] creating static resources
[dmc] deployed 0 static resources
[dmc] creating container
[dmc] [create] metadata container:
[dmc] [create] container member: ApexClass::Test11
[dmc] Deploying...
[dmc] * deploy status: Queued

This has an impact on Tests too. If you specify no arguments, it runs all tests:

$ dmc test --verbose
[dmc] using org: (default)
[dmc] processing 920 records
[dmc] * src/classes/Test1.cls
[dmc] * src/classes/Test2.cls

But if you specify anything else, it fails to find the tests:

$ dmc test --verbose */
[dmc] using org: (default)
[dmc] processing 920 records
[dmc] no tests found that match
[dmc] [OK]

$ dmc test --verbose source/classes/Test1*
[dmc] using org: [email protected] (default)
[dmc] processing 920 records
[dmc] no tests found that match
[dmc] [OK]

And if you copy the test into the 'src' folder, it works!

$ dmc test --verbose src/classes/Test1.cls
[dmc] using org: (default)
[dmc] processing 920 records
[dmc] * src/classes/Test1.cls
[dmc] ===> StagingVersionsTest test results <===
[dmc] [pass] Test1:Method1
[dmc] [pass] Test1:Method2
[dmc] [pass] Test1:Method3
[dmc] [pass] Test1:Method4
[dmc] [OK]

It would be useful to have the option to ignore certain files in the globbing pattern.

Most notably, mm.log files:

[dmc] * src/classes/UserDetails.cls
[dmc] * src/classes/UserDetails.cls-meta.xml
[dmc] * src/classes/Visualization.cls
[dmc] * src/classes/Visualization.cls-meta.xml
[dmc] * src/classes/Visualization_Test.cls
[dmc] * src/classes/Visualization_Test.cls-meta.xml
[dmc] * src/classes/mm.log
[err] missing file: src/classes/mm.log-meta.xml
[dmc] * src/triggers/MetricAssignmentTrigger.trigger
[dmc] * src/triggers/MetricAssignmentTrigger.trigger-meta.xml
[dmc] * src/triggers/MetricFilterTrigger.trigger
[dmc] * src/triggers/MetricFilterTrigger.trigger-meta.xml
[dmc] * src/triggers/MetricTrigger.trigger
[dmc] * src/triggers/MetricTrigger.trigger-meta.xml
[dmc] * src/triggers/ScorecardLogTrigger.trigger
[dmc] * src/triggers/ScorecardLogTrigger.trigger-meta.xml
[dmc] * src/triggers/UserAssignmentTrigger.trigger
[dmc] * src/triggers/UserAssignmentTrigger.trigger-meta.xml
[dmc] * src/triggers/mm.log
[err] missing file: src/triggers/mm.log-meta.xml
[dmc] * src/permissionsets/Scorecard_Admin.permissionset
[dmc] * src/permissionsets/Scorecard_Manager.permissionset
[dmc] * src/permissionsets/Scorecard_User.permissionset
[dmc] * src/permissionsets/mm.log
[err] missing file: src/staticresources/email.resource-meta.xml
[err] missing file: src/staticresources/mm.log-meta.xml
[err] missing file: src/components/mm.log-meta.xml
[err] missing file: src/pages/mm.log-meta.xml
[err] missing file: src/classes/mm.log-meta.xml
[err] missing file: src/triggers/mm.log-meta.xml
[err] cannot deploy - missing files
Error: cannot deploy - missing files
    at /Users/duncan/.nvm-fish/v0.12.2/lib/node_modules/dmc/commands/deploy.js:437:25
    at /Users/duncan/.nvm-fish/v0.12.2/lib/node_modules/dmc/node_modules/async/lib/async.js:251:17
    at /Users/duncan/.nvm-fish/v0.12.2/lib/node_modules/dmc/node_modules/async/lib/async.js:200:33
    at /Users/duncan/.nvm-fish/v0.12.2/lib/node_modules/dmc/node_modules/async/lib/async.js

In API version 37 or above, the runTestAsync method no longer supports get requests. This currently returns the following error:

dmc test src/classes/*
[dmc] using org: nforce (default)
[dmc] loaded .dmcignore
[dmc] processing 8 records
[dmc] * src/classes/MyClass_Test.cls
[dmc] * src/classes/MyClass2_Test.cls
[err] HTTP Method 'GET' not allowed. Allowed are POST
[err] HTTP Method 'GET' not allowed. Allowed are POST
[dmc] [NOT OK]

Need to move this to the POST method

Related => jeffdonthemic/nforce-tooling#14

I upgraded dmc to the latest version this week, and noticed that the retrieve command was failing with an error "ENOENT No such file or directory: [userfolder].dmc.tmp\unpackaged\package.xml".

Investigation showed that rather than having an "Unpackaged" folder in the .tmp area, there is one file called "unpackaged_package.xml". The contents of this file seems to be one of the apex classes that was being retrieved.

Another computer using the same DMC version was still retrieving correctly. I noticed that the adm-zip version was different on the two machines. Adm-zip 0.4.7 was working, v0.4.9 was not.

I modified the package.json on the broken machine to specify 0.4.7 as a dependency version and ran npm i in the dmc folder. NPM installed the older version, and DMC immediately is able to retrieve again.

The error was occurring in retrieve.js when trying to use fs.readFileAsync. However, the source of problem is when zip.extractAllToAsync() extracts the zip contents improperly.

Edit: This is an issue on their github: cthackers/adm-zip#220

So the first thing I wanted to deploy required v36 features.

dmc config:set api_version=36
dmc deploy src/objects/objectname
[dmc] using org: orgname (default)
[err] api version v36.0 is not supported
[dmc] [NOT OK]

It would be cool if there was a way to specify which web browser to use for dmc open

Something like:

dmc open --safari

dmc test currently accepts a --ns option, but there are no options to run a specific class or a specific test within a class.

Add the following options:

• --class to filter apex classes by name
• --name to filter tests by name

Options may be used independently or may be combined to provide even more targeted filters for which tests to run.

For now, only exact name matches (case-insensitive) will be supported, although a future iteration could potentially allow globbing patterns ("BR1_*", for example)

Example usage:

dmc test --class AccountTests

dmc test --name BR1_AccountManagerOrRegionManagerRequired

dmc test --class AccountTests --name BR1_AccountManagerOrRegionManagerRequired

dmc test --ns MyManagedPackage --class AccountTests --name BR1_AccountManagerOrRegionManagerRequired

It isn't clear from dmc retrieve -h how I can only pull what's described in my package.xml. I don't want anything more than what's there.

The reason why each command module exports separate run() and cli() functions is so that the run() function can be easily consumed by a non-cli application. Currently, the cli manages taking an org argument and using it to resolve the proper stored oauth data and passed that oauth data into the run function as an options property.

Therefore, if a non-cli application is consuming the run() method, it must provide the oauth data and can't take advantage of the internal oauth/login management of dmc.

I propose that we move this org loading logic to a module that is called within each run() method for commands that require Salesforce communication. I think the api for the run method should support either (a) the org argument, (b) the oauth argument, or (c) neither that results in falling back to default orgs in the configuration. The loader would handle the negotiation of the arguments to figure out how to return the required oauth.

I got the following logs when retrieving code.

[dmc] using org: pm
[dmc] matching types
[dmc] * matched type: ApexComponent
[dmc] * matched type: ApexPage
[dmc] * matched type: CustomObject
[dmc] * matched type: Workflow
[dmc] * matched type: ApexClass
[dmc] * matched type: ApexTrigger
[dmc] retrieve status: InProgress
[dmc] retrieve status: InProgress
[dmc] retrieve status: InProgress
[err] socket hang up
[dmc] [NOT OK]

We need a default to request only native code versus code from a managed package with a flag to request all metadata.

I'm currently working on a managed package and figured I'd use DMC to pull my project's metadata from our packaging org; none of the packaged code was retrieved. I saw #19 was a closed issue; would it be possible to provide a flag to specify namespaces that should be included in retrieve calls?

There is an open CVE that affects dmc because of its dependency on Handlebars 2.0.0. The recommended fix is to upgrade to 4.x

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8861

It would be super cool to be able to pass command line arguments to an anon script. These could be merged like so...

myscript.apex

Integer num = {{num}}; // merge argument
Integer type = '{{type}}'; // merge argument

List<Account> accs = new List<Account>();

if(type == 'Account') {
  for(Integer i=0; i<num; i++) {
    // do stuff
  }
}

running dmc anon with arguments

$ dmc anon -f myscript.apex --num 6 --type Account

Hello,

I have noticed there is an issue with deploying folders under documents. It would seem that the check to determine if the file should have the -meta.xml does not consider that there may be nested folders in there?

I have an existing test class called MyExt_Test.cls. When watching with dmc watch, the tooling api attempts to deploy this file but it fails to match it's id and throws a duplicates value on record error.

This issue doesn't happen if you watch while forcing the deploy with the metadata api (i.e. dmc watch --meta)

[dmc] using org: asdev36 (default)
[dmc] now watching 1016 files
[dmc] file changed: src/classes/MyExt_Test.cls
[dmc] searching for local metadata
[dmc] deploying 1 metadata files
[dmc] deploy mode: dynamic
[dmc] deploy api: tooling
[dmc] loading related metadata ids
[dmc] loaded 0 ids
[dmc] creating stub files
[dmc] [create] ApexClass::MyExt_Test
[err] duplicate value found: <unknown> duplicates value on record with id: <unknown>
[err] deploy failed: re-watching files