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

.github/workflows/bundle-with-config.yml
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.

.github/workflows/bundle-with-config.yml
      - 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.

CI Job Configuration with Debug enabled

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:

.github/workflows/bundle-with-config.yml
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:

.github/workflows/bundle-with-config.yml
  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.

.github/workflows/bundle-with-config.yml
  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