DUCT

Doing
Unique
CI
Things

A pattern for creating per patch test environments, running end-to-end-tests, and reporting to GitLab or Gerrit

Stef Dunlap (she/her)

staff software engineer in test at WMF, embedded on Abstract Wikipedia team

Get in touch
sdunlap@wikimedia.org
KindRowboat (volunteer)
SDunlap-WMF (Wikimedia Staff)
https://tilde.town/~kindrobot
kindrobot@tiny.tilde.website

Problem Statement

It's currently hard to automate creating per-patch test environments for Wikimedia extensions or services that integrate with other Wikimedia services

Previous failed approaches

Approach Why didn't it work?
The Pipeline (jenkins/zuul) tests are designed to spin up and test one container per job
Patch demo Cannot deploy custom/specified Wikimedia services
Daily Beta Cluster selenium tests shared tenant environment where we don't control the deploy schedule

DevEx Demo: (0) the page before

DevEx Demo: (1) publish a patch for review

DevEx Demo: (1) publish a patch for review

DevEx Demo: (2) results

DevEx Demo: (3) visit environment

DevEx Demo: (4) check pipeline

DevEx Demo: (5) check test results

DUCT Component Diagram

DuctTape

DuctTape is the only custom code in DUCT. It's a rust app that runs on Toolforge, and is designed to be obsolete when Gerrit to GitLab migration completes

Component diagram after Gitlab migration


After all of our gerrit repos are moved to Gitlab, Gitlab CI can interface directly with Gitlab, and there's no need for DuctTape.

Helm chart

Helm is a Kubernetes configuration and deployment tool.

Your app may already have a production Helm chart that your can adopt for CI.

You can also define tests to run against a deployment with helm test.

Wikifunction Helm chart for CI is on GitLab.

Relevant repos

name description
duct this presentation, documentation
aw-ci-chart the Helm chart for Wikifunctions CI environments
aw-e2e the GitLab CI pipeline for deploying that ducttape interfaces with

Thank you :D