tvl-depot/ops/pipelines
Vincent Ambo 6edfdd0773 refactor(ops/pipelines): Query build status from Buildkite API
Instead of manually tracking the build status through Buildkite
metadata, use the Buildkite GraphQL API in the `🦆` build
step (i.e. the one that determines the status of the entire pipeline
to be reported back to Gerrit) to fetch the number of failed jobs.

This way we have less manual state accounting in the pipeline.

The downside is that the GraphQL query embedded here is a little hard
to read.

Notes:

  * This needs an access token for Buildkite. We already have one for
    besadii which is also run by the agents, so I've given it GraphQL
    permissions and reused it.

  * I almost introduced a very rare bug here: My initial intuition was
    to simply `exit $FAILED_JOBS` - in the extremely rare case where
    `$FAILED_JOBS % 256 = 0` this would mean we would ... fail to fail
    the build :)

Change-Id: I61976b11b591d722494d3010a362b544efe2cb25
2021-11-29 23:38:24 +03:00
..
depot.nix refactor(ops/pipelines): Query build status from Buildkite API 2021-11-29 23:38:24 +03:00
fallback.yaml feat(ops/pipelines): Add a fallback Buildkite configuration 2020-11-17 22:33:11 +00:00
README.md docs: Update README for the repository itself 2020-08-17 21:52:58 +00:00
static-pipeline.yaml refactor(ops/pipelines): Query build status from Buildkite API 2021-11-29 23:38:24 +03:00

This folder contains the dynamic configuration for our Buildkite CI setup.

The configuration is built and dynamically loaded by Buildkite at the start of each CI pipeline.