# Upload Action This action is responsible for uploading a package or image to the Chassy index. This is useful for uploading a package to Chassy to be used within the execution of a workflow. {% hint style="info" %} The maximum sizes for packages and images are 1 GB and 50 GB respectively. To import packages more than 1 GB, use the [#import-package](https://docs.chassy.io/reference/workflow-components/steps#import-package "mention") step in a Workflow. {% endhint %} ## Authentication To authenticate with Chassy API you need to supply an authentication token. Please consult our documentation on how to [generate-chassy-tokens](https://docs.chassy.io/operator-guides/generate-chassy-tokens "mention"). The GitHub action consumes this value from an environment variable called `CHASSY_TOKEN`. Ideally, this secret information is stored within a GitHub action secret (see [GitHub Documentation](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions)) and can then be referenced within your workflows as follows: ```yaml env: CHASSY_TOKEN: ${{ secrets.CHASSY_TOKEN }} ``` With this token provided, you can continue with configuration. ## Configuration This action has eight configuration options – six of which are required. ### Name Name of the package being uploaded. You can reference your package by this name in the Chassy Index. {% hint style="info" %} Name is required for all upload types except `EXECUTABLE` {% endhint %} {% hint style="warning" %} Name will be ignored when type is `EXECUTABLE` and path globs multiple files. {% endhint %} ### Path The `path` parameter specifies a fully qualified or glob path to locate your file. Your glob patterns may match multiple files, but this is only acceptable when uploading a type of `ARCHIVE` and `EXECUTABLE` with some slight differences in behavior. Some valid examples include: * `**/release/web` * `**/*.zip` * `./target/release/web` When a path glob of type `EXECUTABLE` matches multiple files, each file is uploaded as an independent package with a name matching the uploaded file. This behavior differs from path globs of type `ARCHIVE` where the entire matching files are uploaded as a single zipped artifact resulting in a single package. {% hint style="info" %} When path globs multiple executables, the provided `name` is ignored in favor of the filename. {% endhint %} ### Architecture The `architecture` parameter specifies the architecture of the machine intended to be hosting the image. The supported values for architecture as follows: * `"AMD64"` * `"ARM64"` * `"ARMv6"` * `"ARMv7"` * `"RISCV"` * `"UNKNOWN"` ### OS The `os` parameter specifies the operating system of the intended host machine. It accepts any string. This value is used to check for ABI compatibility for deployment to fleets. Some examples include: * `ubuntu` * `debian` * `archlinux` ### OS Version The `os_version` parameter specifies the version of the operating system for maintaining ABI compatibility. It accepts any string. Some examples include: * `22.04` * `12.0` * `2024.11.01` ### Type The `type` parameter specifies the type of package. It is provided as a string, but it only accepts a handful of values: * `"FILE"` * `"ARCHIVE"` * `"IMAGE"` * `"FIRMWARE"` ### Version The optional `version` parameter specifies the version of the package being uploaded. It is not to be used with images. It accepts any string, but it is expected that you use [semantic versioning](https://semver.org). ### Classification The optional `classification` parameter allows you to specify the class of artifact for packages or images. It is provided as a string, but there is a set of accepted values depending on what type you are uploading. For `IMAGE`, the accepted classifications are `RFSIMAGE` and `YOCTO`. For `ARCHIVE`, the only accepted classification is `BUNDLE`. For `FILE`, the accepted values are `EXECUTABLE`, `CONFIG`, and `DATA`. For `FIRMWARE`, the only accepted value is `EXECUTABLE`. ### Partitions The optional `partitions` parameter is a string pointing to a partition spec file. This is only used when uploading an image. This file can match glob patterns but should only match a single file. It is to be a JSON file of the structure below: ```json [ { "filesystemType": "ext4", "mountPoint": "/", "name": "root", "size": "2G", "startSector": 0, "partitionType": "83" } ] ``` This array can have as many partitions as you'd like so long as they fit the structure. All of the fields are required. If you provide no partitions, an empty array will be assumed. ### Compression Scheme The optional `compression_scheme` parameter is a string that specifies the compression scheme used for the image. The accepted values are: * `NONE` * `ZIP` * `TGZ` It's important to understand that specifying a compression scheme will not compress the image. It is simply a way to inform Chassy how the image was compressed beforehand. We do recommend compressing your images before uploading them because they can be quite large. Otherwise, the default value is `NONE`. ### Raw Disk Scheme Raw disk scheme is a string that specifies the raw disk scheme used for the image. The accepted values are: * `IMG` * `ISO` ### Access Access is a string that specifies the access level of the artifact. The accepted values are (although case insensitive): * `PUBLIC` * `PRIVATE` The default value is `PRIVATE`. ### Entrypoint Entrypoint is a multi-line string specifying the entrypoint of the archive. It is similar to a Dockerfile's `ENTRYPOINT` command. Entrypoint is required when uploading an archive and is simply ignored otherwise. ```yaml entrypoint: |- ``` ### Nuances of Archives If your `path` matches multiple files and you're uploading an bundled archive, all of these files will be zipped together as a single archive and uploaded. Under any other circumstances, matching multiple files will result in an error. If your `path` matches a single file that happens to be an archive in itself, it will simply be uploaded without further processing. This is determined based on the file extension. The extensions are the following: * `.zip` * `.tar` * `.gz` * `.deb` * `.rpm` ## Example ### Packages In the example below, a binary intended for ARM64 machines running ubuntu 20.04 is being specified at the glob path `**/release/web`. ```yaml example-pkg-upload: name: Example Package Upload runs-on: ubuntu-latest env: CHASSY_TOKEN: ${{ secrets.CHASSY_TOKEN }} steps: - name: Checkout id: checkout uses: actions/checkout@v4 - name: Upload package id: test-action uses: chassyflow/actions-package-upload@latest with: name: "web" architecture: "AMD64" os: "ubuntu" os_version: "20.04" version: "1.0.0" # package version type: "FILE" path: "**/release/web" classification: "EXECUTABLE" ``` ### Images In the example below, an image intended for ARM64 machines built on ubuntu 20.04 is being specified at the path `images/base.img.zip` and partition data is being specified by the path `images/base.partitions.json`. ```yaml example-img-upload: name: Example image Upload runs-on: ubuntu-latest env: CHASSY_TOKEN: ${{ secrets.CHASSY_TOKEN }} steps: - name: Checkout id: checkout uses: actions/checkout@v4 - name: Upload image id: test-action-with-image uses: chassyflow/actions-package-upload@latest with: name: "base-img" architecture: "ARM64" os: "ubuntu" os_version: "20.04" type: "IMAGE" path: "images/base.img.zip" classification: "RFSIMAGE" partitions: "images/base.partitions.json" compression_scheme: "ZIP" raw_disk_scheme: "IMG" ``` ### Archives In the example below, an archive is being an uploaded and the entrypoint is specified to be the entrypoint.sh file at the root of the zip. ```yaml example-archive-upload: name: Example Archive Upload runs-on: ubuntu-latest env: CHASSY_TOKEN steps: - name: Checkout id: checkout uses: actions/checkout@v4 - name: Upload Archive to Chassy id: test-action uses: chassyflow/actions-upload with: name: 'example-archive' architecture: 'ARM64' os: 'ubuntu' os_version: '22.04' type: 'ARCHIVE' path: '**/bundle.zip' entrypoint: |- entrypoint.sh ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.chassy.io/operator-guides/integrating-with-github/upload-action.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.