Functions plugin for the SF CLI
npm install @salesforce/plugin-functions
   
Functions plugin for the SF CLI
- plugin-functions
- Usage
- Contributing
- Build
- Clone the repository
- Navigate to the project folder
- Install the dependencies and compile
- Run using local run file.
- Update README.md
- Releases
- Commands
1. Install the SF CLI: Install instructions
2. Then run sf plugins:install @salesforce/plugin-functions:
``sh-session`
$ sf plugins:install @salesforce/plugin-functions
running command...
Now you should be able to run functions commands, e.g. sf generate project, sf login functions
1. Please read our Code of Conduct
2. Create a new issue before starting your project so that we can keep track of
what you are trying to add/fix. That way, we can also offer suggestions or
let you know if there is already an effort in progress.
3. Fork this repository.
4. Build the plugin locally
5. Create a _topic_ branch in your fork. Note, this step is recommended but technically not required if contributing using a fork.
6. Edit the code in your fork.
7. Create commit messages that adhere to the conventional commits specification.
8. Write appropriate tests for your changes. Try to achieve at least 95% code coverage on any new code. No pull request will be accepted without unit tests.
9. Sign CLA (see CLA below).
10. Send us a pull request when you are done. We'll review your code, suggest any needed changes, and merge it in.
External contributors will be required to sign a Contributor's License
Agreement. You can do so by going to https://cla.salesforce.com/sign-cla.
To build the plugin locally, make sure to have yarn installed and run the following commands:
`bashClone the repository
git clone git@github.com:salesforcecli/plugin-functions
To use your plugin, run using the local
./bin/run or ./bin/run.cmd file.`bash
Run using local run file.
./bin/run env list
`Update README.md
To manually regenerate commands in the README.md file after adding or updating run
npx oclif readmeReleases
The following steps are automated for package releases
Version Bump
We use standard-version to determine the next version that will be published. This means that all commits must adhere to the conventional commits specification in order for
standard-version to work.In the case that you have manually bumped the version in the package.json, then the plugin will respect that and publish that version instead of using
standard-version to determine the next version.NOTE: We consider the
chore, style, docs, ci, test commit types to be "non-releasable", meaning that if all the commits are of those types then we do not publish a new version. However, if you've manually bumped the version in the package.json then the plugin will publish that version regardless of the commit types.$3
1. If you've manually bumped the version in the package.json, the prerelease tag will not be added if it's not already there. For example, if you want to do a prerelease for a new major version, you will want to update the package version to
X.0.0-.2. When using the
--prerelease flag, standard-version will bump both the prerelease version and the package version, e.g. 3.0.0-alpha.0 => 3.0.1-alpha.1. See https://github.com/conventional-changelog/standard-version#release-as-a-pre-release for moreChangelogs
standard-version automatically handles this for us as well. Again you must adhere to the conventional commits specification in order for the changelog generation to work.Build
After determining the next version, the plugin builds the package using
yarn build. This means that you must have a build script included in the package.jsonSigning
If you pass the
--sign (-s) flag into the release command, then the plugin will sign the package and verify that the signature exists in S3.Publishing
Once the package has been built and signed it will be published to npm. The command will not exit until the new version is found on the npm registry.
Commands
sf deploy functions
- sf env compute collaborator add
- sf env create compute
- sf env delete
- sf env log
- sf env log tail
- sf env logdrain add
- sf env logdrain list
- sf env logdrain remove
- sf env var get KEY
- sf env var list
- sf env var set
- sf env var unset
- sf generate function
- sf login functions
- sf login functions jwt
- sf logout functions
- sf run function
- sf run function start
- sf run function start container
- sf run function start local
- sf whoami functionssf deploy functionsDeploy a Salesforce Function to an org from your local project.
`
USAGE
$ sf deploy functions -o [--json] [-b ] [--force] [-q]FLAGS
-b, --branch= Deploy the latest commit from a branch different from the currently active branch.
-o, --connected-org= (required) Username or alias for the org that the compute environment should be connected
to.
-q, --quiet Limit the amount of output displayed from the deploy process.
--force Ignore warnings and overwrite remote repository (not allowed in production).
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Deploy a Salesforce Function to an org from your local project.
You must run this command from within a git repository. Only committed changes to Functions are deployed. The active
branch is deployed unless specified otherwise with
--branch.EXAMPLES
Deploy a Salesforce Function:
$ sf deploy functions --connected-org org-alias
Deploy to 'deploy-branch':
$ sf deploy functions --connected-org org-alias --branch deploy-branch
Overwrite the remote repository:
$ sf deploy functions --connected-org org-alias --force
`sf env compute collaborator addAdd a Heroku user as a collaborator on this Functions account, allowing them to attach Heroku add-ons to compute environments.
`
USAGE
$ sf env compute collaborator add -h FLAGS
-h, --heroku-user= (required) Email address of the Heroku user you're adding as a collaborator.
EXAMPLES
Add a Heroku user as a collaborator on this Functions account.
$ sf env compute collaborator add --heroku-user example@heroku.com
`sf env create computeCreate a compute environment for use with Salesforce Functions.
`
USAGE
$ sf env create compute [--json] [-o ] [-a ]FLAGS
-a, --alias= Alias for the created environment.
-o, --connected-org= Username or alias for the org that the compute environment should be connected to.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Create a compute environment for use with Salesforce Functions.
Compute environments must be connected to a Salesforce org. By default the command uses your local environment's
connected org. Use the '--connected-org' flag to specify a specific org. Run 'sf env list' to see a list of
environments.
EXAMPLES
Create a compute environment to run Salesforce Functions:
$ sf env create compute
Connect the environment to a specific org:
$ sf env create compute --connected-org=org-alias
Create an alias for the compute environment:
$ sf env create compute --alias environment-alias
`sf env deleteDelete an environment.
`
USAGE
$ sf env delete [--json] [-e | ] [--confirm ]FLAGS
-e, --target-compute= Environment name.
--confirm=name... Confirmation name.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Delete an environment.
You must include the name of the environment to delete using '--target-compute'. Run 'sf env list' to see a list of
environments.
Running this command will prompt a confirmation. If you want to skip this confirmation, use the '--confirm' flag and
the environment alias to skip confirmation.
EXAMPLES
Delete a compute environment:
$ sf env delete --target-compute environment-alias
Delete without a confirmation step:
$ sf env delete --target-compute environment-alias --confirm environment-alias
`sf env logStream log output for an environment.
`
USAGE
$ sf env log [-e | ] [-n ]FLAGS
-e, --target-compute= Compute environment name to retrieve logs.
-n, --num= Number of lines to display.
EXAMPLES
Stream log output:
$ sf env log --target-compute environment-alias
`sf env log tailStream log output for an environment.
`
USAGE
$ sf env log tail [-e | ]FLAGS
-e, --target-compute= Compute environment name to retrieve logs.
EXAMPLES
Stream log output:
$ sf env log tail --target-compute environment-alias
`sf env logdrain addAdd log drain to a specified environment.
`
USAGE
$ sf env logdrain add [--json] [-e | ] [-l | ]FLAGS
-e, --target-compute= Environment name.
-l, --drain-url= Endpoint that will receive sent logs.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Add log drain to a specified environment.
Both '--target-compute' and '--url' are required flags. '--url' should be a HTTP or HTTPS URL that can receive the log
drain messages.
EXAMPLES
Add a log drain:
$ sf env logdrain add --target-compute environment-name --url https://path/to/logdrain
`sf env logdrain listList log drains connected to a specified environment.
`
USAGE
$ sf env logdrain list [--json] [-e | ]FLAGS
-e, --target-compute= Environment name.
GLOBAL FLAGS
--json Format output as json.
EXAMPLES
List log drains:
$ sf env logdrain list --target-compute environment-alias
List log drains as json:
$ sf env logdrain list --target-compute environment-alias --json
`sf env logdrain removeRemove log drain from a specified environment.
`
USAGE
$ sf env logdrain remove [--json] [-e | ] [-l | ]FLAGS
-e, --target-compute= Environment name.
-l, --drain-url= Log drain url to remove.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Remove log drain from a specified environment.
Both '--target-compute' and '--drain-url' are required flags.
EXAMPLES
Remove a logdrain:
$ sf env logdrain remove --target-compute environment-alias --url https://path/to/logdrain
`sf env var get KEYDisplay a single config variable for an environment.
`
USAGE
$ sf env var get [KEY] [--json] [-e | ]FLAGS
-e, --target-compute= Environment name.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Display a single config variable for an environment.
You must provide the '--target-compute' flag and the key to retrieve.
EXAMPLES
Get a config variable:
$ sf env var get [KEY] --target-compute environment-alias
`sf env var listList your environment's config vars in a table.
`
USAGE
$ sf env var list [--json] [-e | ]FLAGS
-e, --target-compute= Environment name.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
List your environment's config vars in a table.
Use the '--json' flag to return config vars in JSON format.
EXAMPLES
List config vars:
$ sf env var list --target-compute environment-alias
List in JSON format:
$ sf env var list --target-compute environment-alias --json
`sf env var setSet a single config value for an environment.
`
USAGE
$ sf env var set [--json] [-e | ]FLAGS
-e, --target-compute= Environment name.
GLOBAL FLAGS
--json Format output as json.
EXAMPLES
Set a config value:
$ sf env var set [KEY]=[VALUE] --target-compute environment-alias
`sf env var unsetUnset a single config value for an environment.
`
USAGE
$ sf env var unset [--json] [-e | ]FLAGS
-e, --target-compute= Environment name.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Unset a single config value for an environment.
Run 'sf env var list' to see a list of config values that can be unset.
EXAMPLES
Unset a value:
$ sf env var unset --target-compute environment-alias
`sf generate functionCreate a Salesforce Function with basic scaffolding specific to a given language.
`
USAGE
$ sf generate function -l java|javascript|typescript [-n | ]FLAGS
-l, --language=
DESCRIPTION
Create a Salesforce Function with basic scaffolding specific to a given language.
Both '--language' and '--name' are required flags. Function names must start with a capital letter.
EXAMPLES
Create a JavaScript function:
$ sf generate function --function-name myfunction --language javascript
`sf login functionsLog in to Salesforce Functions.
`
USAGE
$ sf login functions [--json]GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Log in to Salesforce Functions.
This step is required to develop or deploy Salesforce Functions.
EXAMPLES
Log in to Salesforce Functions:
$ sf login functions
`sf login functions jwtLogin using JWT instead of default web-based flow. This will authenticate you with both sf and Salesforce Functions.
`
USAGE
$ sf login functions jwt -u -f -i [--json] [-l | ] [-a ] [-d] [-v]FLAGS
-a, --alias= Alias for the org.
-d, --set-default Set the org as the default that all org-related commands run against.
-f, --keyfile= (required) Path to JWT keyfile.
-i, --clientid= (required) OAuth client ID.
-l, --instance-url= The login URL of the instance the org lives on.
-u, --username= (required) Authentication username.
-v, --set-default-dev-hub Set the org as the default Dev Hub for scratch org creation.
GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Login using JWT instead of default web-based flow. This will authenticate you with both sf and Salesforce Functions.
Use this command when executing from a script.
EXAMPLES
Log in using JWT:
$ sf login functions jwt --username example@username.org --keyfile file.key --clientid 123456
Log in and specify the org alias and URL, set as default org and default Dev Hub, and format output as JSON:
$ sf login functions jwt --username example@username.org --keyfile file.key --clientid 123456 --alias org-alias \
--set-default --set-default-dev-hub --instance-url https://path/to/instance --json
`sf logout functionsLog out of your Salesforce Functions account.
`
USAGE
$ sf logout functions [--json]GLOBAL FLAGS
--json Format output as json.
EXAMPLES
Log out:
$ sf logout functions
`sf run functionSend a cloudevent to a function.
`
USAGE
$ sf run function [--json] [-l | ] [-H ] [-p ] [-s] [-o ]FLAGS
-H, --headers=... Set headers.
-l, --function-url= URL of the function to run.
-o, --connected-org= Username or alias for the target org; overrides default target org.
-p, --payload= Set the payload of the cloudevent as a JSON object or a path to a file via @file.json.
-s, --structured Set the cloudevent to be emitted as a structured JSON cloudevent.
GLOBAL FLAGS
--json Format output as json.
EXAMPLES
Run a function:
$ sf run function --url http://path/to/function
Run a function with a payload and a JSON response:
$ sf run function --url http://path/to/function --payload '@file.json' --structured
`sf run function startBuild and run a Salesforce Function.
`
USAGE
$ sf run function start [-p ] [-b ] [-l auto|java|javascript|typescript] [-v]FLAGS
-b, --debug-port= [default: 9229] Port for remote debugging.
-l, --language=
DESCRIPTION
Build and run a Salesforce Function.
Run this command from the directory of your Salesforce Functions project.
This command will run the target function locally (on the same operating system as this CLI), just like the
local
subcommand.EXAMPLES
Build a function and start the invoker
$ sf run function start
Start the invoker with a specific language and port
$ sf run function start --port 5000 --language javascript
`sf run function start container`
USAGE
$ sf run function start container
`sf run function start localBuild and run a Salesforce Function locally.
`
USAGE
$ sf run function start local [-p ] [-b ] [-l auto|java|javascript|typescript]FLAGS
-b, --debug-port= [default: 9229] Port to use for debugging the function.
-l, --language=
DESCRIPTION
Build and run a Salesforce Function locally.
EXAMPLES
Build a function and start the invoker
$ sf run function start local
Start the invoker with a specific language and port
$ sf run function start local --port 5000 --language javascript
`sf whoami functionsShow information on your Salesforce Functions login.
`
USAGE
$ sf whoami functions [--json]GLOBAL FLAGS
--json Format output as json.
DESCRIPTION
Show information on your Salesforce Functions login.
Returns your email and ID. Use '--show-token' to show your Salesforce Functions token.
EXAMPLES
Get account information:
$ sf whoami functions
Show token and output result as JSON:
$ sf whoami functions --show-token --json
``