threexc / yocto-tekton Goto Github PK

All of the hard-coded paths in the various YAML files for sstate, meta-python, etc. should be replaced by PersistentVolume and PersistentVolumeClaim definitions that users can make the sole point of change for running the pipelines.

Users should be able to target a kustomization.yaml with kubectl apply -k to install the necessary bits, rather than having to manually install them. May also be covered by #10

Right now, patches submitted for the meta-python layer are detected using git log filters for changes to recipe files (i.e. ".bb" and ".inc"), but this limits a more complete analysis of what has been submitted, and it isn't portable to other layers as-is because of how it relies on "python" to be in the subject line. There should be a more sophisticated way to collect the relevant data to determine what to build.

Ideally, we should support setup with any of the major container runtimes, instead of just Docker. I am inclined to make CRI-O the default one in the future.

For example, the meta-python pipeline still makes a lot of assumptions about the types of patches coming in. This morning, it is breaking on 0dc78e2f08b534e139bf0e26ce039c4c6eab566a python3-mprpc: remove the recipe, which makes sense because with that patch there won't be any recipe to build.

A stable, "release" version of the meta-python pipeline should avoid the bash/git stuff going on in the script, and use something else, such as pwclient, to identify which recipes to build.

The container registry included is a hacky solution to support the existing test workflow, but it lacks some security measures and ease-of-configuration that would make it more usable to others.

The meta-python-build-patches, meta-python-build-ptest-container, and meta-python-run-ptest tasks currently only present output in their pipeline/task/step logs (CLI or via the Tekton Dashboard). There should be a step/task that sends an email to a user-customizable recipient (e.g. personal email or the openembedded-devel mailing list) available to call after each of these tasks as desired.

The current instructions work, but since they are manual they're still prone to error. Create and test a script that installs and configures a single-node cluster as per the instructions. For now this can be exclusive to Fedora-based systems, but eventually it would be nice to support Ubuntu/Debian/Arch/etc. as well.

There are attempts under the testimage-work branch to get bitbake -c testimage running in a container that lacks kvm and uses SLIRP instead of tun/tap. We need to get that working to enable a full build and test pipeline. While running containers in privileged mode might make things work, that seems less than ideal if we want to support multiple container runtimes and avoid security issues associated with privileged containers.

A better solution might be to use kubevirt to run a VM in the cluster as part of the pipeline...

Either break all core functionality into bash scripts, or into very discrete steps inside the tasks.