Deploy settings in mdapi format #601
Conversation
src/scratchOrgSettingsGenerator.ts
Outdated
| @@ -99,7 +86,8 @@ export default class SettingsGenerator { | |||
| public async deploySettingsViaFolder(scratchOrg: Org, apiVersion: string): Promise<void> { | |||
| const username = scratchOrg.getUsername(); | |||
| const logger = await Logger.child('deploySettingsViaFolder'); | |||
| this.createPackageXml(apiVersion); | |||
| // this.createPackageXml(apiVersion); | |||
| await this.writePackageFile(this.allRecordTypes, this.allbusinessProcesses, this.packageFilePath, apiVersion); | |||
There was a problem hiding this comment.
since writePackageFile is a method on the class, you could use the this. instance props instead of passing them in.
It might be cleaner to put those in an exported function (could be a different file) that would take inputs and return an object.
Then, your tests could pass a few permutations (with/without record types, BP, objectSettings, etc) and verify that the js objects for CustomObject and package.xml comes back as expected.
That'd be a really clean input/output function test that would cover most of the complexity since the test changes lost all the assertions about the xml contents
| return output; | ||
| output = { ...output, ...{ version: apiVersion } }; | ||
| const xml = js2xmlparser.parse('Package', output); | ||
| this.writer.addToZip(xml, packageFilePath); |
There was a problem hiding this comment.
again, imagine how nice the tests for writePackageFile could be if it were a pure function that took the inputs it needed, didn't use this and returned an object
and let something else convert/write the xml (keeping stuff w/ side effects super simple)
| ); | ||
| expect(addToZipStub.callCount).to.equal(1); | ||
| expect(addToZipStub.firstCall.firstArg).to.be.a('string').and.length.to.be.greaterThan(0); | ||
| expect(addToZipStub.firstCall.args[1]).to.include(path.join('objects', 'MyObject.object')); |
There was a problem hiding this comment.
it's writing a file, but not verifying that the file is good.
If you tried to do all these permutations in NUTs, that would be a lot of scratch orgs and you'd have to find a way to check the object settings/record types etc.
that's why the "pure function" approach is good for stuff like this where there's a lot of input/output permutations.
Co-authored-by: Shane McLaughlin <[email protected]>
|
This PR has been closed as a consequence of needing to move this code to V3 here please make your comments on the new PR. |
Deploy settings in mdapi format
Testing notes:
Link: core in
plugin-orgmain branch is ok, then test the beta commands, besides the regular org, customer has provided a custom org that was failing before you can look it up in this issue: forcedotcom/cli#1526@W-11163191@