Unit testing this library does not give adequate confidence in the
working state of the overall system. The provided `systemtest` Makefile
target can be used to run a very broad system-level test using Jenkins
running in a local Docker context. It's not safe to run in CI (requires
bind mounting the Docker socket within the Jenkins container so that it
can actual perform builds) but it's useful for local development.
Change-Id: Ib9645afa993fa7d247321f3307de30bcab627c20
Provides `PipelineBuilder` for reading `.pipeline/config.yaml` and
mapping user-defined pipelines, stages, and execution graphs to actual
Jenkins Pipeline stage definitions.
Provides `Pipeline` class that constructs a "stack" of `PipelineStage`
objects from the user-provided configs, each with its own `NodeContext`
for binding output values to names and consuming bound values from
previous stages.
Provides `PipelineStage` that contains core stage step implementations
based on the existing `service-pipeline` JJB job definition in
`integration/config`. A closure is returned by each stage for passing
off to Jenkins Pipeline stage definitions by the builder.
Steps have a fixed order within a given stage: build, run, publish,
deploy, exports. This allows for concise definition of a stage that
performs multiple steps, and deterministic behavior of default
configuration that references locally bound output values (e.g. the
default configuration of `image:` for an `publish: { type: image }`
publish entry is `${.imageID}`, referencing the image built in the
current stage's `build` step.) If the user needs to change ordering,
they can simply break the stage out into multiple stages.
See the `Pipeline` class for currently supported configuration. Note
that the aforementioned context system allows for user's to make use of
the same value bindings that step implementations use internally. They
can also use the `exports` configuration field to bind new values.
To illustrate the minimally required configuration, the following would
approximate the current `service-pipeline-test-and-publish` JJB job for
a project named "foo".
pipelines:
foo:
directory: src/foo
stages:
- name: test # builds/runs "test" variant
- name: candidate
build: production
publish:
image: true
deploy: # currently only the "ci" cluster
chart: https://releases.wikimedia.org/charts/foo-0.0.1.tgz
test: true
And to illustrate how the "candidate" stage in this example could be
expressed as multiple stages using references to the output names that
steps bind/export:
pipelines:
foo:
directory: src/foo
stages:
- name: tested
- name: built
build: production
- name: published
publish:
image:
id: '${built.imageID}'
exports:
image: '${.imageFullName}:${.imageTag}'
- name: staged
deploy:
image: '${published.image}'
chart: https://releases.wikimedia.org/charts/foo-0.0.1.tgz
test: true
Bug: T210267
Change-Id: I5a41d0d33ed7e9174db6178ab7921f5143296c75
HTML documentation is generated from inline comments for publication on
https://doc.wikimedia.org
Bug: T222199
Change-Id: Iaa330bfb715e48ad6b346d4be4d2b3ca6bd115b8
Writes and posts easy-to-understand Gerrit comments from the Deployment
Pipeline.
This is the alternative to the current circuitous path of
links users of the pipeline are meant to follow to find basic
information about build status, Docker images, and Docker tags.
Adds two new classes that are meant to be invoked from inside a Jenkins
job defined as a Jenkins Pipeline script. By providing access to a few
build parameters from within a Jenkins job, this patch will post a
comment to Gerrit using an output format that will be styled by Gerrit
commentstyles implemented in I5b04aa10d54b6f2587da196c02ebff9bfe5ba166.
Example posted message:
pipeline-dashboard: service-pipeline
pipeline-build-result: SUCCESS (job: service-pipeline, build: 27)
IMAGE:
docker-registry.wikimedia.org/wikimedia/mediawiki-services-citoid
TAGS:
test, latest
Change-Id: I2fc0924996eb1a969fcbf41bac333d3c35cd34ea