Work with packages

How to use the Skedulo CLI to build, register, list, and deploy packages.

Overview

Packages are simply collections of artifacts that can be deployed together.

There are two package types:

  • Local Local packages can be used while developing collections of artifacts and can be deployed to development tenants.
  • Registered Registered packages are packages formalized with a name and version and submitted to Skedulo. These are the only type that can be deployed to Production tenants.

Build a package

A package is a collection of artifacts. To build one, you need to have copies of all the artifacts you wish to include in your package.

These can be retrieved by using artifact get commands or they can be created from scratch. We recommend that these are arranged into folders by artifact type, as per the following example:

├── custom-fields
│   ├── Jobs-MyCustomField.custom-field.json
├── custom-objects
│   ├── MyCustomObject.custom-object.json
└── triggered-action
    └── MyTriggeredAction.triggered-action.json

We also recommend that you store your package in a GitHub source code repository. This will be essential later when registering a package.

For more on working with artifacts, see work with artifacts.

Once you have all the required artifacts for your package, you can use the package command to deploy it into your tenant. This will allow you to test and ensure that the artifacts work.

sked package deploy local -p .

This command will deploy the contents of the given directory, in this case, the one you are currently in (.). Adjust the parameter as required.

If you add or change artifacts, use the sked package deploy local command again to re-deploy the package.

Register a package

Package registration is the process of taking a local package, giving it a name and version, and submitting it to Skedulo. Some benefits:

  • It becomes an immutable representation of the package for that specific name and version.
  • The package is hosted by Skedulo, so it is available at any time for deployment to any of your tenants.
  • Stronger confidence in understanding what changes are made to a tenant due to deploying fixed versions of packages containing specific artifacts.

Prerequisites

  • Must have a “Production” Skedulo team (tenant). The team name will be used for the package name prefix.
  • The package source code must be stored in a GitHub repository.

Steps

  1. Packages require a metadata file containing the package details. Create a file called skeduloPackage.json at the package root with contents similar to the following:

    {
       "name": "my-production-team/my-package-name",
       "formatVersion": "1",
       "packageVersion": "1.0.0",
       "description": "Customizations including Job custom fields and triggered action."
    }
    
  2. Commit and push the package source to your GitHub repository.

    This ensures strong record-keeping on both the source side and the Skedulo side, as we link the package directly to a specific Git commit.

  3. Produce a GitHub Personal Access Token for the repository.

    The token only requires read permission to the repository. Skedulo will use the token to download and register the source code with the package. Skedulo does not store the token.

    See Managing your personal access tokens on GitHub Docs.

  4. Copy the GitHub reference URL.

    Browse the source code repository to the specific commit you wish to register. The URL will look something like:

    • https://github.com/MyOrg/my-package-name/tree/cf00c88e0ddd6e035f3a95776b654348852c3c7e or
    • https://github.com/MyOrg/my-package-name/commit/cf00c88e0ddd6e035f3a95776b654348852c3c7e
  5. Register the package by running the CLI command:

    sked package register --sourceUrl <github-reference-url>
    

    Replace <github-reference-url> with the reference URL from the previous step.

    You will be prompted to enter the GitHub personal access token. Paste in the token, which will be masked:

    Mandatory lookup example

If the package passes validation, you should see a message that the package was successfully registered, along with the details and a list of the artifacts within the package.

List registered packages

To list all the packages registered by your tenants, simply run the command:

sked package list

It is not currently possible to list which of these packages are installed in your tenants.

Deploy packages

Once a package is ready to be applied to your tenant, it can be deployed with the CLI. Some artifacts in a package may have dependencies (for example, a custom field that requires a custom object), and the packaging commands will ensure that artifacts in the package are deployed in the correct order.

Registered packages

A registered package is a collection of artifacts that is hosted by Skedulo. These can be deployed to any of your production and non-production tenants.

Deploy a registered package by running:

sked package deploy registered -p <package-name> --packageVersion 1.0.0

The --packageVersion flag is optional; if not provided then the latest registered version will be deployed.

Local packages

A local package is a collection of artifacts on your local file system. They would typically be deployed to your development tenant for testing purposes.

Local packages cannot be deployed to production tenants.

Deploy an local package to your tenant by running:

sked package deploy local -p .

You can also perform a “dry run” of a package deployment. This will run the deployment against your tenant, but not make any changes. This is useful for testing packages against environments you don’t want to change (e.g., production).

A dry run can be performed by running:

sked package deploy local -p . --dryRun

For more command options, check the help:

sked package deploy local --help

Next steps

Now that you have deployed packages with the Skedulo CLI, check out:

Skedulo CLI command reference

Help and troubleshooting