GitHub Actions
The mankinds/cli action triggers a Mankinds agent, waits for the quality gate result, and fails the workflow when the gate fails.
1. Add the API key as a repository secret
In your repo:
- Settings → Secrets and variables → Actions → New repository secret.
- Name:
MANKINDS_API_KEY. - Value: the key you copied from Mankinds (Settings → API Keys → Create key).
The full key is shown only once at creation: paste it now or rotate the key if you missed it.
2. Drop the workflow file
Create .github/workflows/mankinds-ci.yml at the root of your repo:
name: Mankinds quality gate
on:
pull_request:
branches: [main]
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: mankinds/cli@v1
with:
agent: 00000000-0000-4000-8000-000000000000
api-key: ${{ secrets.MANKINDS_API_KEY }}
Replace 00000000-0000-4000-8000-000000000000 with your Mankinds agent UUID. The CI integration page on the agent generates a snippet pre-filled with the right UUID and the right base URL.
3. Require the check on protected branches (optional)
If you want the gate to actually block a merge:
- Settings → Branches → Branch protection rules → Add rule on
main. - Require status checks to pass before merging.
- Tick
Mankinds quality gatein the list of required checks.
The first run after the workflow is added registers the check name with GitHub. Trigger one run before adding the protection rule.
Options
The required inputs are agent and api-key. Optional inputs are:
base-url: overridehttps://app.mankinds.iofor another deployment.timeout-minutes: maximum wait time before the action fails.comment-on-pr: enable or disable the PR summary when the workflow runs on a pull request.
Security notes
- Store the API key as a GitHub secret, never inline in the workflow file.
- Pin the action to a major tag such as
mankinds/cli@v1. - The action sends CI metadata to Mankinds so the run is traceable. It does not upload your source code.
- The evaluated system endpoint must be reachable from Mankinds.
Troubleshooting
For 401, check the secret value and key scope. For 404, check the agent UUID and organization. For gate_not_configured, configure the quality gate on the agent and rerun the workflow.
See also
- Quality gate configuration: tune the rule that decides pass/fail.
- GitLab CI and Other CI providers: same gate, different runner.