Checks CI/CD setup

GitHub Actions plugin Fastlane plugin Jenkins (using CLI) Universal CLI setup

Prerequisites for CI/CD

To configure Checks to run in a pipeline, retrieve key configuration inputs from your Checks account and Google Cloud project.

Target Checks account and app

When you run Checks in your CI/CD platform, you will need to assign the results to a Checks account and an app that you've connected to that Checks account. To do this, you'll need the Checks Account ID and App ID.

For your Account ID, visit your Account Settings page.

For your App ID, visit your App Settings page.

Authentication

A service account should be used when using Checks in an automation setup, such as CI/CD. For more information on how to create and configure a service account, see Authenticate the CLI.

If using one of the Checks CI/CD plugins, refer to the plugin's documentation for how to provide the credentials.

If using the Checks CLI within your CI/CD system, it is recommended to use CI environment variables to configure your JSON key. For example:

CHECKS_CREDENTIALS=/my/path/to/serviceaccount.json

Configure Checks to run in a CI/CD pipeline

Checks supports the following approaches:

• Checks CI/CD plugins: Checks provides prebuilt plugins for several CI/CD platforms, including GitHub and fastlane. See the side navigation for more.
• Checks CLI: Teams with more complex workflows, or using a build system without a Checks prebuilt plugin, can use the Checks CLI in their CI/CD pipeline. See Setting up using Checks CLI and Universal setup using Checks CLI for details.
• Checks API: For teams with highly customized workflows, Checks offers a robust REST API. Use it to initiate scans, retrieve reports, and tailor the experience to your unique requirements. Find more information in the Checks API documentation.

GitHub Actions

The Checks App Compliance Scan GitHub Action is a seamless way to automate your Checks analysis right from GitHub. For additional information about GitHub Actions, see the GitHub Actions feature page.

Getting started

Actions live in the .github/workflows/ directory within your repository. Start by creating a checks.yml file in the workflows directory.

We recommend the following config in .github/workflows/checks.yml to run Checks App Compliance analysis:

name: Example workflow using Checks
on:
  release:
    types: [published]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@4
      - name: Run Checks App Compliance analysis async
        uses: google-checks/checks-app-scan-github-action@latest
        with:
          account_id: "1234567890"
          app_id: "1234590"
          binary_path: "./example-app.apk"
          wait_for_report: true
          service_account_base64: ${{ secrets.SERVICE_ACCOUNT_JSON }}

This will run the App Compliance analysis when stable and pre-releases publish and display the report results and URL in the workflow run logs (without failing the build).

Configuration

Just as with our CLI, you can configure the GitHub Action to meet the needs of your process. Set custom inputs using the with key.

Inputs

Name	Type	Required	Description
account_id	string	Yes	Checks account ID from Checks settings page
app_id	string	Yes	Checks application ID
binary_path	string	Yes	Path to the application archive: .apk, .aab or .ipa
version	string	No	Default to latest. Checks CLI version to use. It should be in the format vX.Y.Z or be set to latest to always fetch the latest CLI version.
service_account_base64	string	Yes	base 64 encoded content of your service account. Refer to Authenticate Checks with a service account to generate a service account and to storing Base64 binary blobs as secrets
generate_report	boolean	No	Default to true. If false the action won't upload the binary_path to checks. It is useful to test your authentication and other paramaters.
wait_for_report	boolean	No	If false, the action won't wait for the report completion and the pipeline will keep going.
severity_threshold	string	No	With this option, only vulnerabilities of the specified level or higher are reported. Valid values are: PRIORITY POTENTIAL OPPORTUNITY
fail_on	string	No	If ALL, then action will fail if there are any failed checks following severity_threshold condition. It won't fail by default.

Outputs

The action will write to a checks_results.json file.

Example of using Checks App Compliance Scan GitHub Action

By configuring the inputs to the Checks GitHub Action, you can customize if the Checks analysis should run in the background or as part of your testing suite.

Configure Checks to run an analysis in the background on each commit, but not fail the build

name: Example workflow using Checks
on: [push]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@4
      - name: Run Checks App Compliance analysis async
        uses: google-checks/checks-app-scan-github-action@latest
        with:
          account_id: "1234567890"
          app_id: "1234590"
          binary_path: "./example-app.apk"
          service_account_base64: ${{ secrets.SERVICE_ACCOUNT_JSON }}

Configure Checks to fail a release if the analysis finds priority issues

name: Example workflow using Checks
on:
  release:
    types: [published]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@4
      - name: Run Checks App Compliance analysis and fail on issues
        uses: google-checks/checks-app-scan-github-action@latest
        with:
          account_id: "1234567890"
          app_id: "1234590"
          binary_path: "./example-app.apk"
          wait_for_report: true
          severity_threshold: PRIORITY
          fail_on: true
          service_account_base64: ${{ secrets.SERVICE_ACCOUNT_JSON }}

Feedback

Do you have a CI/CD workflow that you'd like to see added to this guide? Let us know at [e-mail].