# Speed up Development Using CI Job Inputs
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](https://github.com/chassyflow/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
{% code title=".github/workflows/bundle-with-config.yml" %}
```yaml
on:
workflow_dispatch:
inputs:
debug:
type: boolean
description: Specify whether to build with debug
required: false
default: false
```
{% endcode %}
In our `workflow_dispatch` block, we can specify `inputs`. GitHub's API for inputs is rather flexible. Please consult their [official documentation](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onworkflow_dispatchinputs) 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.
{% code title=".github/workflows/bundle-with-config.yml" %}
```yaml
- name: Build
run: cargo build $COMPILER_FLAG
env:
COMPILER_FLAG: ${{ github.event.inputs.debug == 'false' && '--release' || '' }}
```
{% endcode %}
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:
{% code title=".github/workflows/bundle-with-config.yml" %}
```yaml
on:
workflow_dispatch:
inputs:
debug:
type: boolean
description: Specify whether to enable debug mode
required: false
default: false
```
{% endcode %}
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.
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.
{% tabs %}
{% tab title="Without Debug" %}
{% endtab %}
{% tab title="With Debug" %}
{% endtab %}
{% endtabs %}
---
# 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/tutorials/speed-up-development-using-ci-job-inputs.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.