Steps

Documents all the different types of steps that can be used within workflows

Import Package

The import package step will import an artifact from an external source into the Chassy Index. The following external sources are supported:

  • Docker Registries

    • AWS ECR

    • Azure Registries

    • DockerHub

    • GitHub Package Registry

    • Google Cloud Registry (GCR)

    • JFrog

    • Quay

    • On Prem Registries

  • Artifactory

  • AWS S3 Bucket

  • Wasabi Bucket

The GitHub Package Registry mentioned here is not to be confused with packages uploaded using our Package Upload Action. Packages uploaded via the Package Upload Action can already be found within the Chassy Index.

In Chassy’s context, artifacts are any inputs, outputs or deliverables produced during the development and delivery process. These artifacts can include applications binaries, compressed archives, container images or file systems. Artifacts play a crucial role in DevOps pipelines, as they enable the automation and traceability of the software delivery process.

The Import Package step type contains of a name, timeout, and configurations of artifact name, source, type, package name, and versioning options.

Details

Type - to bring an artifact into the Chassy Index, create a new step, and select "Import Package" under type.

Name - Under the name field, create a name that accurately describes your Workflow Step. This is what will be used to uniquely identify this step in your Chassy Workflow.

Timeout - Under the Timeout field, select an appropriate duration before giving up on the task. This will prevent the workflow from running indefinitely if there is an issue. A good rule of thumb is to set the timeout to be slightly longer than the expected runtime of the task.

Configuration

Artifact Name - The Artifact Name field specifies the name of the artifact to be imported. This is the name used by the external source. For example, an artifact retrieved from an S3 bucket will be the S3 file path.

Source - The source from which the artifact is to be pulled. To import from a docker registry (AWS ECR, Azure Registries, DockerHub, Google Cloud Registry (GCR), JFrog, Quay, or an on prem registry), select Docker Registry as the source, and the system will automatically infer the hosting service once you provide the container’s fully qualified name under Artifact Name.

Type - The type of package (image, file, archive, etc).

Versioning - These options denote the versioning schema. By default, you can auto-increment the major release, the minor release, or the patch. If you wish to do something more custom, a regex field is present.

  • Auto Increment Major Release: This option will automatically increment the major release number of the artifact each time a new version is created.

  • Auto Increment Minor Release: This option will automatically increment the minor release number of the artifact each time a new version is created.

  • Auto Increment Patch Release: This option will automatically increment the patch release number of the artifact each time a new version is created.

  • Version Regex: This option allows you to specify a custom regular expression to use for versioning. The regular expression must match the version number of the artifact.

There are other configurations that relevant to your chosen source. For example, if you choose to import from AWS S3, you will need to provide a bucket name and file name.

Find Package

The find package step will bring a package from the Chassy Index into the context of a workflow's execution. If you want to deploy a binary to a fleet, this binary will need to be found with find package before it can be deployed.

The Find Package step type contains of a name, timeout, and configurations of package name, version, package ID, and selection order.

Details

Type - To bring in an artifact, create a new workflow step and select “Find and Import” under Type.

Name - Under the name field, create a name that accurately describes your Workflow Step. This is what will be used to uniquely identify this step in your Chassy Workflow.

Timeout - Under the Timeout field, select an appropriate duration before giving up on the task. This will prevent the workflow from running indefinitely if there is an issue. A good rule of thumb is to set the timeout to be slightly longer than the expected runtime of the task.

Configuration

Package Name - The package name is a unique identifier for an artifact within a workspace. It is used to reference the artifact in workflows and other contexts. When creating an artifact, you must specify a package name. The package name must be unique within the workspace and should accurately reflect the contents of the artifact. It is recommended to use a naming convention that is consistent with your organization's standards.

For example, if you are creating an artifact that contains the binaries for a web application, you might use the package name "web-app-binaries".

Chassy will take care of versioning so this should just be the “base name”. We follow the guidelines set in Semantic Versioning.

Version - version of the package (packages are optionally versioned).

Package ID - ID of your preferred package (optional).

Selection order - the order in which collisions are handled when multiple packages are found with the provided configurations.

Deploy

The deploy step distributes releases to a number of machines within a fleet. The key requirement of the deploy step is having an available release. See Release step for how to get a release.

The Deploy step type contains of a name, timeout, and configurations of fleet name, release name, type, machine selection, and optional properties.

Details

Type - To deploy a release, create a new workflow step and select “Deploy” under Type.

Name - Under the name field, create a name that accurately describes your Workflow Step. This is what will be used to uniquely identify this step in your Chassy Workflow.

Timeout - Under the Timeout field, select an appropriate duration before giving up on the task. This will prevent the workflow from running indefinitely if there is an issue. A good rule of thumb is to set the timeout to be slightly longer than the expected runtime of the task.

Depends On - In Chassy, the "Depends On" field allows you to specify other tasks that must complete before the current task can execute. This is useful for ensuring that tasks are executed in the correct order and that dependencies are met.

To specify a dependency, simply enter the name of the task in the "Depends On" field. You can specify multiple dependencies by separating them with commas.

The "Depends On" field is a powerful tool that can help you ensure that your workflows are executed correctly and efficiently.

Configuration

Fleet - Select and list from the dropdown menu the fleet to target.

Release - Select the release to target. Please refer to Release above for more information.

Type - Currently supported types are Testbed and Production, more types coming soon.

Count - Select the number of Machines in the fleet to release to.

Machine Select - If your machine count is set to 1, select which machine you intend to deploy to.

Environment - In the advanced settings, define environment variables to be set in the deployment environment.

Attributes

  • OS Name - the OS the package is to be deployed to.

  • OS Version - the OS version the package is to be deployed to.

  • IP Address - the target machine’s IP address. Only one of hostname or IP address is required.

  • Host Name - the Machines hostname. Only one of hostname or IP address is required.

Properties

  • Key Value - enter an unique key value pair.

Release

The release step allows you to create a versioned selection of packages for use in a deployment.

The Release step type contains of a name, timeout, and configurations of artifact name, source, type, package name, and versioning options.

Details

Type - To release your artifact(s), create a new workflow step and select “Release” under Type.

Name - Under the name field, create a name that accurately describes your Workflow Step. This is what will be used to uniquely identify this step in your Chassy Workflow.

Timeout - Under the Timeout field, select an appropriate duration before giving up on the task. This will prevent the workflow from running indefinitely if there is an issue. This step is short-lived, so a timeout of 2 minutes is appropriate.

Depends On - In Chassy, the "Depends On" field allows you to specify other tasks that must complete before the current task can execute. This is useful for ensuring that tasks are executed in the correct order and that dependencies are met.

When creating a release package, all the deploy packages that it depends on are automatically included in the release package. This simplifies the release process and ensures that all necessary components are included in the deployment.

To specify a dependency, simply enter the name of the task in the "Depends On" field. You can specify multiple dependencies by separating them with commas.

Configuration

Release Name -The Artifact Name field specifies the name of the artifact to be deployed. This is the unique name within the workspace and Chassy will identify and retrieve the package.

Target Chip - This drop down lists all available chips for you to select the one that the release will target.

Manifest - The manifest is a file that is present in every release and contains information on what the release contains. Each file in the release should contain it’s own manifest entry. The configurable fields include the following:

  • Package Name - The name of the release package.

  • Package Version - Select whether to append two default tags (Latest and Current) or Manually input a custom string.

  • Add another Package - Option to add another Manifest entry for another package.

Find Release

Find an existing release and bring it into the context of the workflow. This is ideal for release promotions across fleets or simply reusing a previously created release for a new deployment.

The Find Release step type contains of a name, timeout, and configurations of find from, release name, version, release ID, and selection order.

Details

Type - To bring an existing release into a workflow's context, create a new workflow step and select "Find Release" under type.

Name - Logical name of step. E.g. Get Release

Timeout - Maximum lifetime for the step. If exceeded, the step will fail. The default timeout is one hour.

Depends On - In Chassy, the "Depends On" field allows you to specify other tasks that must complete before the current task can execute. This is useful for ensuring that tasks are executed in the correct order and that dependencies are met.

When creating a release package, all the deploy packages that it depends on are automatically included in the release package. This simplifies the release process and ensures that all necessary components are included in the deployment.

To specify a dependency, simply enter the name of the task in the "Depends On" field. You can specify multiple dependencies by separating them with commas.

Configuration

Find from - States the source from which a release is to be found. It can be found either in the Chassy Index or from an existing fleet deployment.

Release Name - The name of the release you intend to find.

Version - The version of the release you intend to find.

Release ID - (Optionally) specify a particular version of a release. With the ID specified, you won't get as much flexibility in automatic version checks.

Fleet ID - If using a fleet import, specify the ID of the fleet you intend to reference.

Machine ID - If using a fleet import, you can specify a particular machine ID to reference.

Selection Order - The order in which to select based on version. You can select oldest or latest.

Wait

The step pauses the workflow for a specified duration before proceeding to the next step.

Details

Name - Under the name field, create a name that accurately describes your Workflow Step. This is what will be used to uniquely identify this step in your Chassy Workflow.

Timeout - Under the Timeout field, select an appropriate duration before giving up on the task. This will prevent the workflow from running indefinitely if there is an issue. A good rule of thumb is to set the timeout to be slightly longer than the expected runtime of the task.

For Wait, ensure that the timeout is longer than the wait duration.

Depends On - In Chassy, the "Depends On" field allows you to specify other tasks that must complete before the current task can execute. This is useful for ensuring that tasks are executed in the correct order and that dependencies are met.

To specify a dependency, simply enter the name of the task in the "Depends On" field. You can specify multiple dependencies by separating them with commas.

Configuration

Duration - The duration to wait, in milliseconds.

Run CI Job

Run a CI Job in some external service such as GitHub as part of your Chassy Workflow.

The Run CI Job step type contains of a name, timeout, and configurations of type, GitHub Workflow, Repository name and owner, Git Ref, and Job Input options.
Run CI Job configuration options

Details

Name - Under the name field, create a name that accurately describes your Workflow Step. This is what will be used to uniquely identify this step in your Chassy Workflow.

Timeout - Under the Timeout field, select an appropriate duration before giving up on the task. This will prevent the workflow from running indefinitely if there is an issue. A good rule of thumb is to set the timeout to be slightly longer than the expected runtime of the task.

Depends On - In Chassy, the "Depends On" field allows you to specify other tasks that must complete before the current task can execute. This is useful for ensuring that tasks are executed in the correct order and that dependencies are met. This configuration option is only available for steps that do not come first in the Workflow.

To specify a dependency, simply enter the name of the task in the "Depends On" field. You can specify multiple dependencies by separating them with commas.

Configuration

Type* - The type of CI Job you would like to run. The other configurations are all dependent on this one. At the moment, we only support the ability to run GitHub Actions workflows.

Job Input - Arbitrary input to provide to the job. The structure of this data will depend on the needs of the CI Job.

Run GitHub Actions Workflow Configurations

GitHub Workflow* - The name of the file containing the workflow or the ID of the workflow obtained using the GitHub API.

Repository Name* - The name of the repository you wish to run a workflow in.

Repository Owner* - The name of the owner of the repository. This can be a GitHub username or an organization name.

Git Ref* - Indicates the Git ref against which to run the workflow. This is useful for specifying a branch or tag. These do not need to be qualified by heads/ or tags/.

While you can run your workflow against any arbitrary branch, the workflow does need to exist in your default branch for GitHub to recognize it.

Job Input - JSON data to be provided to the workflow

If your inputs are unexpected (i.e. not declared in the workflow definition), you will encounter an error at execution time.

Last updated