vdemeester / buildkit-tekton Goto Github PK

Support all the thing we can support from ContainerSpec

Most likely using github workflow, at least to start with ?

Currently, buildkit-tekton only supports on resource in one file, all embedded. We should be able to parse all and execute all or on, …

In order to dogfood, let's try to use mainly tekton pipeline in our CI
but on github workflow.

This most likely mean, define a "simple" (to begin with)
buildkit-tekton github action that is able to run it with tkn-local.

- uses: vdemeester/tkn-local@v1
  with:
    dirs: .tekton
    run: .tekton/pullrequest.yaml
    pipelines-as-code: true

Open questions

• Should there be an option for tkn-pac so that we do tkn pac resolve … | tkn local run … ?
  I think so 😇

Make it possible to pass arguments to the build. This would be useful for:

• Overidding PipelineRun parameters
• Pass secrets, configmap, …
• Pass options to the frontend
• Specify a "target" to run (if multiple runs)

Create a file from the inline script and add it to right place (according to upstream tekton).
Can take inspiration of how heredoc are implemeted in the dockerfile frontend.

Make sure we take into account PodTemplate when running Pipelines and Tasks

Buildkit has this concept of secret, and we should probably hook into it.

As a non-required check, to see the progress of "support" 😝

Use persistent cache or something for it to be shared across steps

Create some documentation around how to use buildkit-tekton with docker, or buildkit itself, as well as options, shortcomings, …

… and also LICENSE headers maybe ?

As of today, you can only use this frontend with docker build or buildctl (buildkitd). It would be more than nice if we could have a standalone binary that wouldn't require anything else than a container runtime (runc or crun).

See img for inspiration (see here

Mimic what Docker does with FROM here. The idea is to resolve the image, and set the correct options to the state (mainly Run) so that we run in the "normal" conditions.

As of today, using plain output (default when no tty) is relatively verbose and hard to read. We could do something closer to dagger's output instead:

The idea is to make it possible for buildkit-tekton to get read things from a context. That should help supporting multiple files and "fetching" TaskRef/PipelineRef

The idea is to mimic running a PipelineRun with a ServiceAccount that has some secrets attach. The idea is that setting this would make all steps to have a /tetkon/home/… setup properly, according to auth.md

For example, parsing a file with multiple resources, we should/can ignore resources like PersistentVolumeClaim.

Start with all embedded

When parsing, support configmap by creating a file from it.

Depending on what we do not support, warn or error out if the loaded definition has them

If we see a CustomTask (in a Pipeline) how should we act ?
Should we support some (matrix, …) or just error out ?