# Common Deployment Scenarios

## Scenario 1 - Uploading a Fortify FPR with embedded source code

If you have a fortify FPR report with source code embedded, you can run an analysis through Bugsy without needing to connect to your repository. In this case, simply use the analyze mode and use `-p` (`--src-path`) and point it at the FPR file.

For example, let's say we a file call `fortify.fpr` that contains both the SAST report + Source code:

{% code title="sh" overflow="wrap" %}

```
npx mobbdev@latest analyze -f .\fortify.fpr -p .\fortify.fpr -r https://my_repo_url --api-key xxxxxxx
```

{% endcode %}

**Explanation:**

* `-f .\fortify.fpr` specifies the location of the SAST report
* `-p .\fortify.fpr` specifies the location of the source code (in this case embedded in the FPR file)
* `-r https://my_repo_url` specifies the location of the actual repository. We encourage that this field is specified correctly, as it tells Mobb where the fix commits should go to.
* `--api-key xxxxxxx` specify your API key here

## Scenario 2 - Automatically create pull requests for trusted fixes

If you want Mobb to automatically generate pull requests for trusted fixes, you must first enable it under your **Project Settings --> Fix Policy** as shown [here](https://docs.mobb.ai/mobb-user-docs/administration/project-settings#project-level-automatic-pr).

{% code title="sh" overflow="wrap" %}

```
npx mobbdev analyze -f sast_results.json -r https://github.com/mobb-dev/simple-vulnerable-java-project --ref dev --auto-pr --ci
```

{% endcode %}

**Explanation:**

* `--auto-pr` will tell Mobb to respect the fix policy as defined in the project settings and generate a pull request for the issue types where automatic PR is enabled in in the fix policy.

## Scenario 3 - Automatically commit fixes to a target branch

If you want to enable automatic commit for trusted fixes, you must first enable it under your **Project Settings --> Fix Policy,** as shown [here](https://docs.mobb.ai/mobb-user-docs/administration/project-settings#project-level-automatic-pr).

This scenario is typically reserved for directly committing the fixes to a development branch.

{% code title="sh" overflow="wrap" %}

```
npx mobbdev analyze -f sast_results.json -r https://github.com/mobb-dev/simple-vulnerable-java-project --ref dev --auto-pr --commit-directly --ci
```

{% endcode %}

**Explanation:**

* `--auto-pr` will tell Mobb to respect the fix policy as defined in the project settings
* `--commit-directly` will tell Mobb that instead of generating a Pull Request, generate a commit on the branch specified by `--ref dev`

## Scenario 4 - Handling Large FPR Files (50k+ Issues)

When dealing with very large Fortify FPR files (containing 50,000+ issues or exceeding 10GB in internal compressed XML size), you'll need to convert the FPR to SARIF format and compress it before uploading. This approach is necessary because:

* **File size limitations**: Direct FPR uploads are blocked when the internal compressed XML exceeds 10GB
* **Network efficiency**: ZIP compression reduces upload time for slower connections

### Step-by-step process:

**Step 1:** Convert the FPR file to SARIF format

{% code title="sh" overflow="wrap" %}

```
npx mobbdev@latest convert-to-sarif --input-file-path report.fpr --output-file-path report.sarif --input-file-format FortifyFPR
```

{% endcode %}

**Step 2:** Compress the SARIF file into a ZIP archive

{% code title="sh" overflow="wrap" %}

```
tar -a -c -f report.zip report.sarif
```

{% endcode %}

**Step 3:** Upload the compressed SARIF file for analysis

{% code title="sh" overflow="wrap" %}

```
npx mobbdev@latest analyze -f report.zip -r https://<YOUR_REPO_URL> --ref <YOUR_BRANCH> --api-key xxxx --ci
```

{% endcode %}

**Explanation:**

* `convert-to-sarif` converts the large FPR file to SARIF format, which is more efficient for Mobb's backend processing
* `tar -a -c -f` creates a compressed ZIP archive containing the SARIF file
* The final `npx mobbdev@latest analyze` command processes the compressed SARIF file like any other scan report

{% hint style="info" %}
**When to use this scenario:**

* FPR files with 50,000+ issues
* FPR files where the internal compressed XML exceeds 10GB
* Slow network connections where compression significantly reduces upload time
  {% endhint %}
