commit | ccbfbd2e4dcd7bbf264748e151fd6d5d2ba9e013 | [log] [tgz] |
---|---|---|
author | Paul Jolly <paul@myitcv.io> | Thu Jan 14 17:50:29 2021 +0000 |
committer | Paul Jolly <paul@myitcv.org.uk> | Fri Jan 15 17:08:39 2021 +0000 |
tree | cda4a2e57f180ee511efa8be71b1f48a58fcf98e | |
parent | bef7b263893bf64368d00aeb6d3e8cf7976dbdf2 [diff] |
ci: move to build branch model Currently, runtrybot triggers a repository_dispatch build via the test_dispatch workflow. This dispatch workflow then starts the process of updating the CL with a "starting" notification, running the build matrix, and then finally updating the CL with the result state. However, because this all happens as part of the dispatch workflow, it all happens using the _tip_ definitions of the dispatch workflow, not the definition in the commit under test. This means that when we need to make changes to the workflow definition, the try bot result from testing that CL is not the result of using the changes to the workflow in that commit. Hence we must blindly submit that CL and hope that it doesn't break the workflow (the next tip build will tell us but still). This is clearly very brittle. This change switches us to a model of using build branches that are created by the initial repository_dispatch. These branches then trigger a regular branch build, albeit using a special git ref (ci/$CHANGE_ID/$COMMIT). Status updates to the corresponding CL happen as before, but this time from the build branch workflow. When a CL build branch workflow has completed, the corresponding build branch is deleted (regardless of the test result). Note that for now we do not delete this branch: we first want to ensure that a master build succeeds. Note that from a security perspective this is fine (tm). In order to trigger a repository_dispatch event in the first place a user must have write permission to the CUE repo. So there is no privilege escalation here. The initial repository dispatch is triggered by a user with write privileges, but then the subsequent push of the build branch happens as cueckoo. Closes #513 Change-Id: I2738fc488d6a8ef08e7e83b151b12934b9f1ee15 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/8212 Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
Configure, Unify, Execute
CUE is an open source data constraint language which aims to simplify tasks involving defining and using data.
It is a superset of JSON, allowing users familiar with JSON to get started quickly.
You can use CUE to
CUE merges the notion of schema and data. The same CUE definition can simultaneously be used for validating data and act as a template to reduce boilerplate. Schema definition is enriched with fine-grained value definitions and default values. At the same time, data can be simplified by removing values implied by such detailed definitions. The merging of these two concepts enables many tasks to be handled in a principled way.
Constraints provide a simple and well-defined, yet powerful, alternative to inheritance, a common source of complexity with configuration languages.
The CUE scripting layer defines declarative scripting, expressed in CUE, on top of data. This solves three problems: working around the closedness of CUE definitions (we say CUE is hermetic), providing an easy way to share common scripts and workflows for using data, and giving CUE the knowledge of how data is used to optimize validation.
There are many tools that interpret data or use a specialized language for a specific domain (Kustomize, Ksonnet). This solves dealing with data on one level, but the problem it solves may repeat itself at a higher level when integrating other systems in a workflow. CUE scripting is generic and allows users to define any workflow.
CUE is designed for automation. Some aspects of this are:
Using Homebrew, you can install using the CUE Homebrew tap:
brew install cuelang/tap/cue
If you already have Go installed, the short version is:
go get -u cuelang.org/go/cmd/cue
This will install the cue
command line tool.
For more details see Installing CUE.
The fastest way to learn the basics is to follow the tutorial on basic language constructs.
A more elaborate tutorial demonstrating of how to convert and restructure an existing set of Kubernetes configurations is available in written form.
Language Specification: official CUE Language specification.
API: the API on godoc.org
Builtin packages: builtins available from CUE programs
cue
Command line reference: the cue
command
Our canonical Git repository is located at https://cue.googlesource.com.
To contribute, please read the Contribution Guide.
To report issues or make a feature request, use the issue tracker.
Changes can be contributed using Gerrit or Github pull requests.
You can get in touch with the cuelang community in the following ways:
Unless otherwise noted, the CUE source files are distributed under the Apache 2.0 license found in the LICENSE file.
This is not an officially supported Google product.