1. Create an issue describing the bug or enhancement you want to propose (select the right issue template).
2. Make sure the issue has been reviewed and agreed.
3. Create a Merge Request, from your **own** fork (see [forking workflow](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html) documentation).
3. Create a Merge Request, from your **own** fork (see [forking workflow](https://docs.gitlab.com/user/project/repository/forking_workflow/) documentation).
Don't hesitate to mark your MR as `Draft` as long as you think it's not ready to be reviewed.
| `image` / `RUST_IMAGE` | The Docker image used to run `cargo` | `docker.io/library/rust:latest`<br/>[](https://to-be-continuous.gitlab.io/doc/secu/trivy-RUST_IMAGE) |
| `rustflags` / `RUST_RUSTFLAGS` | Compiler flags to pass to all [`rustc`](https://doc.rust-lang.org/rustc/) invocations. | _none_ |
| `clippy-disabled` / `RUST_CLIPPY_DISABLED` | Set to `true` to disable the Clippy analysis | _none_ (enabled) |
| `clippy-args` / `RUST_CLIPPY_ARGS` | Clippy [options and arguments](https://doc.rust-lang.org/clippy/usage.html#command-line).<br/>:warning: Be sure to prefix with `--` for clippy arguments. | `--all-targets --all-features -- --deny warnings` |
In addition to logs in the console, this job produces the following report:
| `$RUST_PROJECT_DIR/reports/rust-clippy.native.json` | [JSON](https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/languages/rust/#clippy-integration) | [SonarQube integration](https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/importing-external-issues/external-analyzer-reports/)<br/>_This report is generated only if SonarQube template is detected_ |
### `rust-depcheck` job
### `rust-audit` job
This job enables a manual [dependency check](link-to-the-tool) analysis of your code, mapped to the `test` stage.
This job runs [`cargo audit`](https://rustsec.org/) to scan for vulnerabilites in the dependencies. It is mapped to the `test` stage.
It uses the following variables:
| Input / Variable | Description | Default value |
This job is **disabled by default** and performs a publish of your built binaries.
This job is **disabled by default** and performs a [`cargo publish`](https://doc.rust-lang.org/cargo/commands/cargo-publish.html) of your cargo project.
It uses the following variables:
| Input / Variable | Description | Default value |
| `publish-enabled` / `RUST_PUBLISH_ENABLED` | Set to `true` to enable publish | _none_ (disabled) |
| `publish-args` / `RUST_PUBLISH_ARGS` | Arguments used by [`cargo publish`](https://doc.rust-lang.org/cargo/commands/cargo-publish.html) | _none_ |
| :lock: `RUST_PUBLISH_TOKEN` | [crates.io](https://crates.io/) API Token used by [`cargo publish`](https://doc.rust-lang.org/cargo/commands/cargo-publish.html) | **must be defined** when using [crates.io](https://crates.io/) |
| :lock: `CARGO_REGISTRIES_<registry_name>_TOKEN` | _registry_name_ API Token used by [`cargo publish`](https://doc.rust-lang.org/cargo/commands/cargo-publish.html) | **must be defined** when using an alternate registry |
:information_source: Currently, [GitLab does not support cargo registries](https://docs.gitlab.com/user/packages/package_registry/supported_package_managers/).
#### Using an alternate registry
An alternate registry (other than [crates.io](https://crates.io)) can be configured in the in a
[`.cargo/config.toml`](https://doc.rust-lang.org/cargo/reference/config.html). More information is available [here](https://doc.rust-lang.org/cargo/reference/registries.html#using-an-alternate-registry)
> Example configuration:
>
> ```toml
> # .cargo/config.toml
>
> [registries]
> my-registry = { index = "https://my-intranet:8080/git/index" }
> ```
>
> Specify the registry token with :lock: `CARGO_REGISTRIES_MY_REGISTRY_TOKEN`.
### Secrets management
Here are some advices about your **secrets** (variables marked with a :lock:):
1. Manage them as [project or group CI/CD variables](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui):
-[**masked**](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) to prevent them from being inadvertently
1. Manage them as [project or group CI/CD variables](https://docs.gitlab.com/ci/variables/#define-a-cicd-variable-in-the-ui):
-[**masked**](https://docs.gitlab.com/ci/variables/#mask-a-cicd-variable) to prevent them from being inadvertently
displayed in your job logs,
-[**protected**](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable) if you want to secure some secrets
-[**protected**](https://docs.gitlab.com/ci/variables/#protect-a-cicd-variable) if you want to secure some secrets
you don't want everyone in the project to have access to (for instance production secrets).
2. In case a secret contains [characters that prevent it from being masked](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable),
2. In case a secret contains [characters that prevent it from being masked](https://docs.gitlab.com/ci/variables/#mask-a-cicd-variable),
simply define its value as the [Base64](https://en.wikipedia.org/wiki/Base64) encoded value prefixed with `@b64@`:
it will then be possible to mask it and the template will automatically decode it prior to using it.
3. Don't forget to escape special characters (e.g.: `$` -> `$$`).