Policies

Updated 2 years ago by Admin

The Drone policy file gives you the ability to define policies that set and enforce pipeline values. For example, this gives you the ability to set namespace, tolerations and more based on organization, repository and other matching criteria.

Example policy file:

1  ---
2  kind: policy
3  name: octocat
4
5  match:
6   repos:
7   - "octocat/*"
8    - "octocat/hello-world"
9
10 metadata:
11   namespace: octocat
12
13 resources:
14   request:
15     cpu: 1
16     memory: 512MiB
17   limit:
18     cpu: 4
19     memory: 1GiB
20
21 node_selector:
22   disktype: ssd
23
24 ---
25 kind: policy
26 name: default
27
28 metadata:
29   namespace: default

The policy file must be mounted into your runner container and you must provide the runner the location of the policy file. See the policy configuration parameter for configuration instructions.

Multiple Policies

You can define multiple policies in the policy file. The match section is used to match the policy the pipeline. The first matching policy is applied to the pipeline.

1  ---
2  kind: policy
3  name: octocat
4
5  match:
6    repos:
7   - "octocat/*"
8   - "octocat/hello-world"
9 
10 metadata:
11  namespace: octocat
12
13 ---
14 kind: policy
15 name: default
16 
17 metadata:
18   namespace: default

Default Policies

You can optionally define a default policy in the policy file, named accordingly. The default policy is applied if no other policy matches the pipeline.

1  ---
2  kind: policy
3  name: octocat
4
5  match:
6    repos:
7    - "octocat/*"
8    - "octocat/hello-world"
9
10 metadata:
11  namespace: octocat
12
13 ---
14 kind: policy
15 name: default
16
17 metadata:
18   namespace: default

File Format

  • kind
    The kind attribute defines the kind of object.
  • name
    The name attribute defines a name for your policy.
  • metadata
    The metadata section defines metadata attached to the pipeline pod.
    • namespace
      The namespace attribute defines the namespace in which the pipeline pod is created. This takes precedence over the value defined in the yaml.
    • annotations
      The annotations attribute defines a set of arbitrary key / value pairs that are attached to the pipeline pod. These are appended to existing annotations that are defined in the yaml and take precedence on conflict.
    • labels
      The annotations attribute defines a set of arbitrary key / value pairs that are attached to the pipeline pod. These are appended to existing labels that are defined in the yaml and take precedence on conflict.
  • resources
    The resource attribute defines resource requirements and limits for pipeline steps.
    • request
      The request section defines resource requirements used when the scheduler defines which node to place the pipeline pod on.
    • cpu
      The cpu attribute defines cpu requirements.
    • memory
      The memory attribute defines memory requirements.
  • limit
    The limit section defines container resource limits applied to each pipeline step.
    • cpu
      The cpu attribute defines cpu limits.
    • memory
      The memory attribute defines memory limits.
  • service_account
    The service_account attribute defines the kubernetes service account used to create the pipeline pod. This takes precedence over the value defined in the yaml.
  • node_selector
    The node_selector attribute defines a set of key / value pairs used to route pipeline pods to matching nodes. This takes precedence over the values defined in the yaml.
  • tolerations
    The tolerations section defines and applies tolerations to pipeline pods to schedule onto nodes with matching taints.
    • effect
      The effect attribute defines the taint effect.
    • key
      The key attribute defines the toleration key.
    • operator
      The key attribute defines the toleration operator.
    • toleration_seconds
      The key attribute defines the toleration seconds.
    • value
      The key attribute defines the toleration value.

Examples

  • Example policy sets the default service account:
    1 kind: policy
    2 name: default
    3
    4 service_account: drone
  • Example policy sets the default service account for matching pipelines:
    1 kind: policy
    2 name: default
    3
    4 service_account: drone
    5
    6 match:
    7   repos:
    8   - "octocat/*"
    9   - "octocat/hello-world"
  • Example policy sets the default namespace:
    1 kind: policy
    2 name: default
    3
    4 metadata:
    5   namespace: default
    6
    7 match:
    8   repos:
    9   - "octocat/*"
    10  - "octocat/hello-world"
  • Example policy sets the default resource limits:
    1  kind: policy
    2  name: default
    3  
    4  metadata:
    5    namespace: default
    6 
    7  resources:
    8    request:
    9      cpu: 1
    10     memory: 512MiB
    11   limit:
    12     cpu: 4
    13     memory: 1GiB
  • Example policy sets the default node selection:
    1 kind: policy
    2 name: default
    3 
    4 metadata:
    5   namespace: default
    6 
    7 node_selector:
    8   disktype: ssd
  • Example policy sets the default metadata:
    1  kind: policy
    2  name: default
    3  
    4  metadata:
    5    namespace: default
    6    labels:
    7      keyA: valueA
    8      keyB: valueB
    9   annotations:
    10     keyA: valueA
    11     keyB: valueB

How did we do?