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:
CI Auto-Detection
Section titled “CI Auto-Detection”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.
General Pattern
Section titled “General Pattern”All CI integrations follow the same pattern:
- Create an organization API key on the API Keys page of the Cloud Platform and store it as
a secret named
HOUNDDOG_API_KEYin your CI system. - Run
hounddog scanin a job, either in thehounddogai/hounddogDocker image or with the binary installed on the runner. Results upload to the Cloud Platform automatically. - Optionally add
--fail-severity-thresholdto 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.
