cki_tools.sprinter

Implement the CKI workflow

This webhook enforces the CKI workflow and manages the CWF::* labels on issues and merge requests.

Iterations

The webhook listens to issue/epic updates and updates labels and iterations:

  • if a closed issue if is not assigned to an iteration yet, assign them to the current sprint
  • if a closed issue is not yet tagged with an CWF::Sprint::* label, tag with CWF::Sprint::Unplanned
  • if an open issue is assigned an iteration, ensure that it is also tagged with an CWF::Sprint::* label; if the issue is not tagged yet, tag with CWF::Sprint::Planned
  • if an open issue is not assigned an iteration, ensure that it is not tagged any CWF::Sprint::* labels
  • if an open issue is part of an open epic tagged with CWF::Stage::Refined or CWF::Stage::In Progress, tag it with CWF::Planning::Current; remove this label again if that changes

Incident labels

The webhook listens to issue updates and updates the CWF::Incident::* and CWF::Type::Incident labels so they stay consistent when using the incident board:

  • if an open issue is tagged with CWF::Incident::*, tag with CWF::Type::Incident
  • if an open issue is tagged with CWF::Type::Incident, but no CWF::Incident::*, tag with CWF::Incident::Active
  • if the CWF::Type::Incident label is removed from an open issue, remove any CWF::Incident::* labels
  • if an issue is closed, remove CWF::Incident::*

Recurring issues

The webhook listens to issue updates and updates the CWF::Recurring::* and CWF::Type::Recurring labels so they stay consistent:

  • if an open issue is tagged with CWF::Recurring::*, tag with CWF::Type::Recurring
  • if an open issue is tagged with CWF::Type::Recurring, but no CWF::Recurring::*, tag with CWF::Incident::Automatic
  • if the CWF::Type::Recurring label is removed from an open issue, remove any CWF::Recurring::* labels

Additionally, a cron job is available to clone recurring issues into new sprints (see below).

Team labels

The webhook listens to issue updates and adds correct CWF::Team::* labels:

  • if an issue is not already tagged with CWF::Team::*, tag with CWF::Team::* depending on the project/group as specified in the configuration

Stage labels

The webhook listens to issue updates and ensures correct CWF::Stage::* labels:

  • if an issue is closed, remove CWF::Stage::*

The webhook listens to merge request changes and enforces the presence of an issue link in the merge request description.

The resulting labels are CWF::Issue::OK (link found) or CWF::Issue::Missing (link missing). Labels are updated on changes to the merge request. A label update can be requested by manually removing the current label from the merge request.

Automatic weights

The webhook listens to issue updates and adds a default weight if missing.

Resolution labels

The webhook listens to issue updates and ensures correct CWF::Resolution::* labels:

  • When an issue is closed, if no resolution label is present, it will automatically add either CWF::Resolution::Done or CWF::Resolution::Duplicate (if closed as a duplicate).
  • If an issue is closed as a duplicate, its weight is set to 0.
  • If a resolution label is added to an open issue, the issue will be closed. If the label is not Done, the weight will also be set to 0.
  • If a resolution label is present when an issue is (re)opened, the label will be removed. If the weight was previously set to 0, it will be reset to the configured default weight (if any).

Usage

usage: python3 -m cki_tools.sprinter [-h] [--message MESSAGE] [--validate]
           [--clone-recurring] [--expiry-period EXPIRY_PERIOD] [--group-url GROUP_URL]

options:
  -h, --help            show this help message and exit
  --message MESSAGE     process given message and exit
  --validate            only validate configuration and exit
  --clone-recurring     clone recurring issues when close to the end of the sprint
  --expiry-period EXPIRY_PERIOD
                        customize interval for issue cloning before sprint closure
  --group-url GROUP_URL
                        GitLab group to use for the recurring issue check

Cron job

For cloning recurring issues, the sprinter can also be run as a cron job. When close to the end of the sprint, the --clone-recurring option will clone all issues in the GitLab group specified by the --group-url option marked as CWF::Recurring::Automatic into the next sprint. The --expiry-period option can be used to customize the interval for cloning recurring issues. The default is 6 hours before the end of the sprint.

Configuration

The configuration in SPRINTER_CONFIG can be provided in YAML or JSON format:

---
# select projects for MR issue checks
issue_checks:
  # project-level rule
  - project: https://instance/group/project
    enabled: false  # defaults to enabled
  # all projects beneath the group
  - group: https://instance/group
    enabled: false
  # add labels at project level instead of group
  - project: https://instance/group/foo
    level: project
  # only for issues that belong to a certain team
  - team_label: 'CKI'
  # disable for everything else
  - enabled: false
# select projects for issue sprint labels
sprint_labels: []
# select projects for issue incident labels
incident_labels: []
# select projects for recurring issue labels
recurring_issues: []
# select projects for issue type labels
type_labels:
  # add a certain issue type label
  - project: https://gitlab.com/cki-project/kernel-ark
    type: 'ARK'
# select projects for automatic weights
automatic_weights:
  - project: https://gitlab.com/cki-project/cki-tools
    weight: 5
# select projects for resolution labels
resolution_labels:
  - project: https://gitlab.com/cki-project/cki-tools
    level: project
    weight: 0  # default weight for non-duplicates (optional, defaults to 0)
labels:
  - name: CWF::Team::CKI
    color: '#6699cc'
    description: "This issue belongs to the CKI team."

Environment variables

Environment variable Secret Required Description
SPRINTER_CONFIG no yes Configuration in YAML, falls back to SPRINTER_CONFIG_PATH
SPRINTER_CONFIG_PATH no no Path to a single configuration YAML file
GITLAB_TOKENS no yes URL/environment variable pairs of GitLab instances and private tokens
GITLAB_TOKEN yes yes GitLab private tokens as configured in GITLAB_TOKENS above
RABBITMQ_HOST no yes RabbitMQ host
RABBITMQ_PORT no no RabbitMQ port, TLS is used for port 443
RABBITMQ_USER no yes RabbitMQ user
RABBITMQ_PASSWORD yes yes RabbitMQ password
RABBITMQ_CAFILE no no RabbitMQ CA file path
RABBITMQ_CERTFILE no no RabbitMQ certificate + private key file path
CKI_DEPLOYMENT_ENVIRONMENT no no Define the deployment environment (production/staging)
CKI_LOGGING_LEVEL no no logging level for CKI modules, defaults to WARN
SENTRY_SDN yes no Sentry SDN

CKI_DEPLOYMENT_ENVIRONMENT

On non-production deployments (CKI_DEPLOYMENT_ENVIRONMENT != production), no changes to GitLab objects are made.