Speed up Development Using CI Job Inputs
Our Run CI Job step allows you to optionally specify parameters to provide to your external CI service. This guide will go over a handful of things you can do with an example Rust project.
While this guide focuses on a Rust example project, these ideas can come in handy for development in all sorts of different technologies. We will be pulling examples from our cargo-workspace-example repository.
Optimize Build Times when Debugging
Rust has infamously slow compile times. When trying to rapidly test and iterate, this can be a pain point. Using CI job inputs and Rust compiler profiles, we can cut down on our minutes spent in CI. During local development, cargo will compile in debug mode for quicker compile times. Depending on the size of your project, this can increase compiler speed by anywhere from 2-10 times. In our example, our time compiling is cut in half.
Add inputs to your GitHub Actions Workflow
on:
workflow_dispatch:
inputs:
debug:
type: boolean
description: Specify whether to build with debug
required: false
default: false
In our workflow_dispatch
block, we can specify inputs
. GitHub's API for inputs is rather flexible. Please consult their official documentation for more information.
We can now update our compile step to build in debug mode if this input is set to true
. Otherwise, compile in release mode.
- name: Build
run: cargo build $COMPILER_FLAG
env:
COMPILER_FLAG: ${{ github.event.inputs.debug == 'false' && '--release' || '' }}
This somewhat terse syntax just states that the COMPILER_FLAG
variable should be defined as --release
if debug is disabled or an empty string if debug is enabled. We then run our command as usual but append $COMPILER_FLAG
to it.
Now if we enable this parameter in the Chassy Console, we can see our build times get cut down.

Then if you want to begin compiling in release mode again, simply remove the input from your configuration or set it to false
.
Enabling/Disabling Tests and Checks
Consider a situation similar to the one we just considered. I'm quickly iterating and don't want to run certain tests or checks. I can accomplish this using job inputs too.
You could create individual inputs controlling the execution of each check, but for this example, we will simply skip linting, testing, and formatting if we're running in debug mode. As in the first example, ensure you have a debug input:
on:
workflow_dispatch:
inputs:
debug:
type: boolean
description: Specify whether to enable debug mode
required: false
default: false
Then for each check, you conditionally skip it with an if
condition like so:
cargo-test:
name: Cargo Test
runs-on: ubuntu-latest
if: ${{ !inputs.debug }}
steps:
- name: Checkout
id: checkout
uses: actions/checkout@v4
- name: Run tests
run: cargo test
In our example, we do the same for the cargo-clippy
and cargo-fmt
checks as well. Now let's make sure these checks either pass or are skipped before we build and upload the bundle.
build_and_upload:
name: Build and Upload
runs-on: ubuntu-latest
needs: [cargo-test, cargo-fmt, cargo-clippy]
if: |
always() &&
(needs.cargo-test.result == 'success' || needs.cargo-test.result == 'skipped') &&
(needs.cargo-fmt.result == 'success' || needs.cargo-fmt.result == 'skipped') &&
(needs.cargo-clippy.result == 'success' || needs.cargo-clippy.result == 'skipped')
env:
CHASSY_TOKEN: ${{ secrets.CHASSY_TOKEN_DEV }}
BACKEND_ENV: DEV
steps:
If we disable the debug
input, these checks are simply skipped and we then build in debug mode. Below illustrate the difference in workflow execution.

Last updated