LUCI Change Verifier
LUCI Change Verifier (CV) is the LUCI microservice that is replacing LUCI CQDaemon, while providing the same or better functionality.
CV is already responsible for starting and completing the Runs, which includes CL Submission.
As of August 2021, CV work group is working on second milestone moving the remaining functionalities off CQDaemon and onto CV (tracking bug https://crbug.com/1225047).
TODO(crbug.com/1225047): update this doc.
- api: Protobuf files specifying the public API of CV, such as per-project config spec, PubSub messages and RPCs definitions. APIs organization is a bit messy right now, but of note are 2 versions:
- v0: experimental API under development. Request an approval from CV owners before using it.
- v1: stable API, which won‘t be broken unless absolutely necessary. As of Sep 2021, it’s under the development.
- appengine: the entry point for a GAE app.
- internal: GAE-agnostic implementation details in Go. See
godoc-based overview here. Notably:
- internal/cvtesting/e2e high level end-to-end level CV tests, which cover the most important business logic in a fairly readable and concise way. The test are run against a fake Gerrit.
- internal/changelist: encapsulates a changelist (a.k.a. CL, patch, Gerrit Change).
- internal/acls: enforces ALCs.
- internal/tryjob: manages tryjobs (i.e. Buildbucket builds) which are used to verify a CL.
- internal/prjmanager and sub-packages: decides when to start new Runs given the state of all CLs in an individual LUCI project.
- internal/run and sub-packages: handles individual Run from its creation to completion.
- internal/rpc pRPC handlers, including “admin” API not exposed in public
go run main.go
# See output for URLs to http URLs.
To work with Runs from the -dev project, connect to its Datastore by adding these arguments:
go run main.go -cloud-project luci-change-verifier-dev`
For a quick check, eyeball these two pages (your port may be different):
Finally, you can deploy your work-in-progress to -dev project directly.
How does this code end up in production?
tl;dr this the usual way for LUCI GAE apps. Roughly,
CL lands in
luci-go (this) repo.
Autoroller rolls it into
infra/infra repo (example).
- pro-tip: If autoroller is stuck, you can create your own DEPS roll with
roll-dep go/src/go.chromium.org/luci in your
Tarball with only the necessary files is created by the Google-internal
Newest tarball is automatically rolled into also Google-internal
infradata-gae repo (example).
gae-deploy builder auto-deploys the newest tarball to
luci-change-verifier-dev GAE project.
Someone manually bumps tarball version to deploy to production
luci-change-verifier via a CL (example).
The same Google-internal
gae-deploy builder deploys the desired version to production
luci-change-verifier GAE project.