Prepare for building meta machines on jenkins

We are preparing to build anacapa, bletchley15, santabarbara, ventura2,
and yosemite5 on jenkins. This ensures that when those new jobs start
running on the jenkins workers, they will be fast since the sstate
will have data for each of the new machines.

Signed-off-by: James Athappilly <jamesatha@gmail.com>
Depends-on: Iae149f1da8822f48783199b51858a07fdaa476e2
Change-Id: Id6bb685014ac7d4e4978f11717462e216b10c7f2
1 file changed
tree: fed55abf130a66049d44201f0d232027243e0459
  1. config/
  2. jenkins/
  3. scripts/
  4. tools/
  5. .gitignore
  6. .shellcheck
  7. build-rootfs-size-docker.sh
  8. build-setup.sh
  9. LICENSE
  10. OWNERS
  11. qemu-build.sh
  12. README.md
  13. run-qemu-robot-test.sh
  14. run-rootfs-size-docker.sh
  15. run-unit-test-docker.sh
README.md

openbmc-build-scripts

Build script for CI jobs in Jenkins.

Linter policy and related build failures

Formatting linters sometimes change stylistic output across releases. Separately, some linters are not version-pinned in the CI container, as pinning would drive either frequent maintenance with upgrades or stagnation of the code-base against older versions.

The combination may result in inconsistent formatting opinions across CI worker nodes[^1].

If you see such behaviour consider changing the thing to force a container refresh.

[^1]: The collection of container builds across all worker nodes may not hold a consistent set of tool versions despite being built from the same specification: The inconsistencies emerge from the cadence of upstream tool package updates beating against the cadence of container rebuilds on the worker nodes.