This is a repository of configuration files meant for maintaining the layers of the Yocto Project. It originated as a simple set of Tekton pipeline resources for Kubernetes that were (and are still) used to help maintain the meta-python layer, but it continues to evolve to support other layers and related processes, in addition to serving as a set of examples for building pipelines with Docker, k8s, and Tekton.
See the instructions for configuring a k8s cluster in the coming sections to get started.
The Dockerfiles are used to handle the majority of the deployments and pipelines created through the rest of the repository's content.
- Dockerfile-buildspace is the catch-all container for actual builds, which includes all of the tools necessary to successfully run bitbake for various recipes;
- Dockerfile-nettools is a container that is best used as a debug pod when testing new deployments, pods, etc. and their configurations (e.g. if you want to make sure that an httpd deployment is exposed where you think it is)
See fedora_setup.md
The meta-python pipelines are examples of how one might build a CI/CD pipeline that performs common Yocto layer maintainer tasks. There are two different pipelines:
- patch-pipeline
- container-pipeline
Both of these share a common task, "update-workspace", which clones the poky, meta-openembedded, and yocto-tekton repositories into the hostPath specified in the pipelines (or updates these repositories to the latest master, master-next, and main commits, respectively, if the repos are already present). Each pipeline also comes with a distinct EventListener and CronJob that will automatically trigger them once per day.
patch-pipeline does the following:
- Identify any patches applied to the master-next branch of the meta-openembedded layer that are for meta-python recipes and adds the recipe names to a build list;
- Triggers a build of all of those recipes with bitbake;
- Outputs a short list of all of the identified and built recipes after completion (if the builds succeeded)
container-pipeline:
- Builds the meta-python-ptest-image target as a container filesystem;
- Uses Kaniko to build a container image from the completed ptest image and pushes it to a local registry;
- Pulls the image from that registry to run as the container for a test task, and executes the "ptest-runner" command
Both of these pipelines make basic use of Kubernetes' built-in Kustomize functionality to simplify templating the individual pipelines, share resource templates (such as the aforementioned update-workspace task), and instantiate supporting services (such as the yt-registry deployment that container-pipeline uses to store its test images). For the end-user, this ultimately means that adding these pipelines to the single-node cluster can be as simple as running this command inside the container-pipeline and/or patch-pipeline directories:
kubectl apply -k .
Note: The TriggerTemplate spec in each pipeline has a hostPath value of /tekton/pipelines/meta-python, which is specific to the author's system. If you want the pipeline build artifacts to be created in a different location, you will need to edit this field, or create the /tekton/pipelines/meta-python path on the cluster node and ensure it that the correct permissions are set.
While both meta-python pipelines feature automatic runs thanks to their CronJob/EventListener combinations, it is possible to trigger them manually as required. To help in doing so, the author also created a "nettools" pod for the single-node cluster that can be used to (among other things) trigger the builds.
The nettools pod is created by running:
kubectl run -i --tty --attach nettools --image=threexc/nettools
If it is instantiated but you are not currently attached, you can attach to it by running:
kubectl exec -it nettools -- /bin/bash
And then running the following (check the EventListener naming conventions for exact syntax):
curl -X POST http://el-meta-python-listener.tekton-pipelines.svc.cluster.local:8080
Finally, tkn pipelinerun logs --last -f -n tekton-pipelines or the
Tekton Dashboard allow viewing of the in-progress or complete pipelines.
- Helm doesn't like "generateName" fields (making adding the Tekton parts to the chart difficult): helm/helm#3348
- Better patch queue/identification for meta-python and poky pipelines
- Start using stuff from the Tekton Catalog
- Get QEMU working in the testimage container
- Do it with KVM and tap/tun
TOC generated with the help of gh-md-toc
GIFs generated with peek