Deploy an Artifact

You can deploy both containers and binaries with the Chassy platform. This guide contains instructions for both.

This guide assumes you have created a fleet. If you have not created one, it is recommended you read the Fleet User Guide first.

If you're unfamiliar with Chassy Workflows, then starting with the Workflow User Guide is a good resource.

Create a new Workflow

Docker

1. Go to the workflows section and select create a new workflow. We can name it “Deploy Docker to fleet”.

2. We assume a fleet has already been created prior, so we will simply select “Test Fleet”

3. Click “Create Workflow” to move onto the next step

Binary

1. Go to the workflows section and select create a new workflow. We can name it “Deploy Binary to fleet”.

2. We assume a fleet has already been created prior, so we will simply select “Test Fleet”

3. Click “Create Workflow” to move onto the next step

Add “Import Package” Task

Docker

1. There will be an empty unconfigured step called “Step 1” present. Select it and rename it to “Retrieve Docker Artifact”. Under the details menu, select “Import Package”. For the timeout, select a reasonable timeout for the download, such as 600 seconds.

2. Under configuration, for artifact name enter the artifact name that is stated in the Github Actions (GHA) job. We will assume it’s gha_docker for this example.

3. For Source, select "Github Actions Workflow". We assume that a certain GHA such as creating a release branch will trigger the generation of a docker container, and we’re retrieving that artifact.

4. For Type, select “Container”

5. Name the package name “application_docker_contaner”.

6. For versioning, we will auto increment the minor release and thus select that option.

Binary

1. There will be an empty unconfigured step called “Step 1” present. Select it and rename it to “Retrieve Binary Artifact”. Under the details menu, select “Import Package”. For the timeout, select a reasonable timeout for the download, such as 600 seconds.

2. Under configuration, for artifact name enter the artifact name that is stated in the Github Actions (GHA) job. We will assume it’s gha_binary for this example.

3. For Source, select "Github Actions Workflow". We assume that a certain GHA such as creating a release branch will trigger the generation of a binary, and we’re retrieving that artifact.

4. For Type, select “Binary”

5. Name the package name “application_binary”.

6. For versioning, we will auto increment the minor release and thus select that option.

Add “Release” Task

Docker

1. Locate the icon of the “Retrieve Docker Artifact” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Retrieve Docker Artifact” task.

2. Under the details menu, select “Release” as the Type. Name this to be “Configure Release”. Set a reasonable value for the timeout, such as 300s. You will observe that the “Retrieve Docker Artifact” task is already listed as a dependency on the “depends on” field.

3. In the Configuration menu, under Release Name, enter a descriptive name for the release we’re about to create. We’ll call it “application_docker_release”.

4. We need to select the target chip this release will target. We assume that fleets and chips have already been previously defined, so we will simply select “x86_ubuntu24.04_LTS”.

5. Under Manifest, we will now add fields to our release manifest. The rule of thumb is to add one manifest entry for each package. Since we only have one docker container to deploy, we only need one field. In the future if we have multiple packages to release, we can click the “Add another package” option to add another package entry. Under package name, we can use the same name we chose in the “Retrieve Docker Artifact”’s package name task, “application_docker_container”.

6. For the package version, we will simply use the latest.

Binary

1. Locate the icon of the “Retrieve Binary Artifact” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Retrieve Binary Artifact” task.

2. Under the details menu, select “Release” as the Type. Name this to be “Configure Release”. Set a reasonable value for the timeout, such as 300s. You will observe that the “Retrieve Binary Artifact” task is already listed as a dependency on the “depends on” field.

3. In the Configuration menu, under Release Name, enter a descriptive name for the release we’re about to create. We’ll call it “application_binary_release”.

4. We need to select the target chip this release will target. We assume that fleets and chips have already been previously defined, so we will simply select “x86_ubuntu24.04_LTS”.

5. Under Manifest, we will now add fields to our release manifest. The rule of thumb is to add one manifest entry for each package. Since we only have one binary to deploy, we only need one field. In the future if we have multiple packages to release, we can click the “Add another package” option to add another package entry. Under package name, we can use the same name we chose in the “Retrieve Binary Artifact”’s package name task, “application_binary”.

6. For the package version, we will simply use the latest.

Add “Deploy” Task

Docker

1. Locate the icon of the “Configure Release” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Configure Release” task.

2. Under the details menu, select “Deploy” as the Type. Name this to be “Deploy Container”. Set a reasonable value for the timeout, such as 300s. You will observe that the “Configure Release” task is already listed as a dependency on the “depends on” field.

3. Under Fleet, select the fleet to target. Since we already have a preconfigured fleet, we select “Test Fleet San Francisco”.

4. Under “Release”, enter “application_docker_release” from the field above.

5. Under Type, we will select “Testbed”.

6. Under Count, we select “All” to release to the whole fleet.

7. Under Attributes, we append some important information about what we’re deploying to. Under OS Name, we state Ubuntu Base. Under OS Version, we state 24.04. We leave IP address blank and enter the machine’s hostname “bot01”.

Binary

1. Locate the icon of the “Configure Release” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Configure Release” task.

2. Under the details menu, select “Deploy” as the Type. Name this to be “Deploy Binary”. Set a reasonable value for the timeout, such as 300s. You will observe that the “Configure Release” task is already listed as a dependency on the “depends on” field.

3. Under Fleet, select the fleet to target. Since we already have a preconfigured fleet, we select “Test Fleet San Francisco”.

4. Under “Release”, enter “application_binary_release” from the field above.

5. Under Type, we will select “Testbed”.

6. Under Count, we select “All” to release to the whole fleet.

7. Under Attributes, we append some important information about what we’re deploying to. Under OS Name, we state Ubuntu Base. Under OS Version, we state 24.04. We leave IP address blank and enter the machine’s hostname “bot01”.

Complete and Run the Workflow

1. On the top right of the workflow graph, select create workflow. This will create the workflow and you can see it newly created in the Workflows tab as well as it’s status.

2. Next we will need to hook it up to a github action so it’s run automatically.