| Tweet |
Introduction
As regular readers of this blog will know, I’m a big fan of the command line in general and the Salesforce CLI in particular. Up until now I’ve been layering functionality onto the CLI by wrapping it in bash or node scripts, so I was interested to read about the Plugin Development beta program as this seemed like a neater way to extend it.
The examples I’ve seen to date are mainly focused on extracting information from the org, or performing local processing on files that have already been generated by another CLI command, so I wanted to push things a little further and change something in the org. In the command line tool that I’ve written to manage our BrightMedia projects we update the org with a bunch of information, including the Git commit id, after a successful deployment, and this felt like a good challenge to start with
Creating the Plugin
Simply following the instructions from the plugin generator Github repo gave me the initial version of the plugin. This creates fairly hefty folder structure, but the most interesting bit is the src/commands folder - anything I put in here becomes a command for my plugin and the folder structure from here down gives me the topic/subtopic etc.
I have the structure :
which gives me the topic bbuzz and the command gitstamp. This concluded the simple part of creating my plugin.
More to Learn
The example plugin that the generator creates is coded in TypeScript, a typed superset of JavaScript that compiles down to plain old JavaScript. I hadn’t used this before, but it’s not too different to JavaScript so I was able to get going reasonably quickly, with the compiler telling me what I’d missed or broken.
The Command
A plugin command needs to extend SfdxCommand - I inadvertently left the name of mine as Org, which is the name for the command created by the plugin generator, but thus far it hasn’t caused me any problems.
export default class Org extends SfdxCommand {
and as I will be connecting to an org I’ll need to enable that. I also want this to be executed from a SalesforceDX project, as the name of the custom setting and the specific field to write the commit id to can be overridden through the sfdx-project.json file:
protected static requiresUsername = true; protected static requiresProject = true;
I then fetch the configuration from the project configuration file, supplying defaults if no config is found:
const projectJson = await this.project.retrieveSfdxProjectJson();
const settingConfig = _.get(projectJson.get('plugins'),'bb.gitSetting');
const settingName=settingConfig.settingName || 'Git_Info__c';
const commitIdField=settingConfig.commitIdField || 'Commit_Id__c';
I then query the setting from the org, as if there is already one I need to update it with it’s id:
const query = 'Select Id, SetupOwnerId, ' + commitIdField + ' from ' + settingName + ' where SetupOwnerId = \'' + orgId + '\'';
interface Setting{
Id? : string,
SetupOwnerId : string,
[key: string] : string
}
// Query the setting to see if we need to insert or update
const result = await conn.query<Setting>(query);
let settingInstance : Setting;
settingInstance={"SetupOwnerId": orgId};
if (result.records && result.records.length > 0) {
settingInstance.Id=result.records[0].Id
}
Note that I define a typescript interface for the custom setting. As I don’t know the name of the field that the commit id will be stored in, I just define the generic [key:string] rather than a specific name.
Then I get the current commit id and fill that in on the settingInstance:
const util=require('util');
const exec=util.promisify(require('child_process').exec);
const {error, stdout, stderr} = await exec('git rev-parse HEAD');
const commitId=stdout.trim();
settingInstance[commitIdField]=commitId;
Then I had to figure out how to insert or update the custom setting record. Checking the Org class of the Salesforce DX Core library didn’t show me many options, but after a short while I realised that the core library is built on top of jsforce, and sure enough Connection extends jsforce.Connection which had the CRUD commands that I needed:
let opResult;
if (settingInstance.Id) {
opResult=await conn.sobject(settingName).update(settingInstance);
}
else {
opResult=await conn.sobject(settingName).insert(settingInstance);
}
this.ux.log('Done');
if (!opResult.success) {
this.ux.log('Error updating commit id' + JSON.stringify(opResult.errors));
}
else {
this.ux.log('Stamped the Git commit id in the org');
}
and finally I output a JSON format result string so that if I need to use it in a script I can:
return { orgId: this.org.getOrgId(),
commitId: commitId,
success: opResult.success,
errors: opResult.errors };
Something I wasn’t expecting was that every time I made code changes, simply executing the plugin caused it to be recompiled, which was a real time saver.
Publishing
Once I had my plugin working, I then had to figure out how to publish to the npm.js registry - once again I hadn’t done this before so it was another opportunity to learn. Luckily this is well documented so it wasn’t as hard as I was expecting. There’s a little bit of hoop jumping around creating the releases on Github, but I’d recently been through at least this aspect with my training system.
Take it for a Spin
To try out the plugin, follow the instructions on the npm page. If you’d like to dig into the code, it's available at the Github repo.
Related Posts
- SFDX and the Metadata API Part 4 - VSCode Integration
- SFDX and the Metadata API Part 3 - Destructive Changes
- SFDX and the Metadata API Part 2 - Scripting
- SFDX and the Metadata API (Part 1 of this series)
- Selenium and SalesforceDX Scratch Orgs
- Create Your First Salesforce CLI Plugin (Salesforce Developers Blog Post by René Winkelmeyer)
- Developing Plugins for the Salesforce CLI (Salesforce Developers Blog Post by Dave Carroll)
