Shepherdly Repo Config

Setup

Shepherdly customized per repository with a yml config file. It can be placed anywhere in the repo but the filename must end with shepherdly.yml .

The config file must be introduced and subsequently modified through pull requests. Changes directly to the default branch will be ignored.

Basic Behavior

Changes do not take effect until the pull request containing the file are merged into the default (ex: main or master ) branch.

Each change to the yml file will undergo a schema validation. A comment will be posted to the file directly indicating if the schema has passed or if errors exist.

Inheritance

Config files can inherit and extend from parent configurations in a polymorphic manner by referencing a parent_config_name . Shepherdly must have permissions to the repository containing the parent config.

To setup a config so that it can be inherited, specify a config_name .

Example:

Parent:

config_name: ui-shepherdly.yml
configurations:
  - name: scoring_comment_enabled
    value: true

Child:

parent_config_name: ui-shepherdly.yml
configurations:
  - name: scoring_comment_draft_mode
    value: true

In this example above, the child config would inherit the scoring_comment_enabled value but also override the system default scoring_comment_draft_mode .

Configurations

Name	System Default Value	Description
`scoring_comment_enabled`	false	Toggles the PR bot comment.
`scoring_comment_risk_score_threshold`	0	Determines the minimum risk score required to trigger the PR bot comment.
`scoring_comment_draft_mode`	false	Toggles the PR bot for PRs in 'draft' state.
`buggy_file_hotspot_percentile_threshold`	0.90	The minimum percentile needed for a file to be classified as a buggy hotspot. The default is a good balance of signal to noise.
`qa_git_team_name`	none	If exists, name of team that is responsible for QA.
`integration_test_path`	none	Comma separated value of directories that contain integrations tests.
`file_path_exclusions`	none	Comma separated value of directories that don't contain any executable production code.

Mitigations

Out of the box

These are mitigations that are supported by default and can be auto-detected using AST parsing in supported languages.

Name	Risk Score Threshold
`code_review`	0
`integration_test`	50
`unit_test`	50
`feature_flag`	75
`observability`	75

Specific thresholds can be overridden:

mitigations:
  - name: observability
    score_threshold: 80
  - name: feature_flag
    score_threshold: 80

System default mitigations can be disabled entirely and delegate to whatever is specified in the repo mitigations by setting `default_system_mitigations` to `false`. :

configurations:
mitigations:
  - name: code_review
    score_threshold: 0
  - name: feature_flag
    score_threshold: 80
  - name: unit_test
    score_threshold: 50
  - name: observability
    score_threshold: 70
default_system_mitigations: false

Custom Mitigations

Custom mitigations don't have any default auto-detection capability but still allow for them to be marked as required given a precise risk score. Engineers can manually attest to their completion and is trackable in the web app.

Similar to default mitigations, completion of custom mitigations increases resilience coverage metric of the PR.

mitigations:
  - name: run_security_scan
    score_threshold: 80
    custom: true
    label: Run Security Scan

URL & String templating

Custom mitigation labels can be URL's with some string templating to help with deep linking by specifying the label_url property.

The available contextual variables is currently just the Pull Request Number the comment resides in: {{pr_number}} .

mitigations:
  - name: run_security_scan
    score_threshold: 80
    custom: true
    label: Run Security Scan
    label_url: https://api.acme.com/scan/{{pr_number}}

Webhooks

Webhooks can be enabled for users who want to tail the risk score stream. It provides the current risk score and resilience coverage, along with basic information about the pull request.

webhooks:
  - url: https://api.acmecorp.com/some/path