Skip to content

The HoundDog.ai code scanner runs in any CI system that can execute a Linux binary or a Docker container. Setup guides are available for:

The scanner automatically detects when it runs inside AppVeyor, Azure Pipelines, Bitbucket Pipelines, Buddy, Buildkite, CircleCI, Codeship, Drone CI, GitHub Actions, GitLab CI/CD, Jenkins, Semaphore CI, Shippable, TeamCity, and Travis CI, and adjusts its output and metadata collection accordingly. Use the --ci flag to override the detection if needed.

The example pipelines on the following pages pass --ci explicitly anyway. Detection of Azure Pipelines, Bitbucket Pipelines, Buildkite, Jenkins, and TeamCity was fixed after the initial release, so passing the flag keeps those pipelines working on older scanner versions too. It matters most when running the Docker image: without a detected or declared CI system, the scanner assumes a local Docker scan and looks for the code at /data instead of the checkout directory.

HOUNDDOG_GIT_BRANCH and HOUNDDOG_GIT_COMMIT are consulted only when the repository’s HEAD cannot be resolved at all, and only in CI systems that have no dedicated branch variables (Azure Pipelines, Jenkins, TeamCity, Shippable). They do not override a detached-HEAD checkout — re-attach HEAD before scanning if your CI checks out a detached HEAD and you need the real branch name.

All CI integrations follow the same pattern:

  1. Create an organization API key on the API Keys page of the Cloud Platform and store it as a secret named HOUNDDOG_API_KEY in your CI system.
  2. Run hounddog scan in a job, either in the hounddogai/hounddog Docker image or with the binary installed on the runner. Results upload to the Cloud Platform automatically.
  3. Optionally add --fail-severity-threshold to block the build when risky dataflows at or above a severity are found. The scanner exits with code 1 in that case — after uploading the results, so the Cloud Platform always stays up to date.