I've talked about this a bit with @bobcatfish in the past, and maybe others, but I wanted to float it here before writing up a full TEP (and I wanted to try out GitHub Discussions 😎 )

Tekton could inject a basic shell into steps, similar to how we inject the entrypoint binary, by adding an initContainer that copies a binary into a shared volume under /tekton/something. This would let steps that don't include a shell to take advantage of script: and perform basic actions in the step environment.

We've had some TEPs (#302, #182, #342, others) that boil down to "I want to do something shell-ey, and my image doesn't have a shell". This would give us an avenue to solve those cases without reimplementing shell-like features in Tekton itself.

Examples

steps:
- image: gcr.io/go-containerregistry/crane  # image doesn't provide a shell
  script: |
    #! /tekton/tools/sh
    crane cp foo bar || exit 0  # ignore failure

steps:
- image: gcr.io/go-containerregistry/crane
  script: |
    #! /tekton/tools/sh
    crane push foo > /tekton/results/image-digest  # redirect output to results

How

busybox provides a shell and basic tools in a single binary inside a multi-arch image (supports amd64, arm, arm64, ppc64le, s390x, plenty of others). Busybox is GPL, so if that's a problem we could find another alternative.

Considerations

• Security: Maybe operators don't want to provide a shell, perhaps for security reasons; how would they disable it? They might want to disable it for the entire installation, or for only certain pipelines or tasks or steps.
• Configuration: Operators should be able to configure what image provides the shell, like they do with image flags on the controller today. Tekton's vanilla installation should come with
• Architecture portability: Any image Tekton chooses by default should support as many CPU architectures as possible
• OS portability?: Someday Tekton would like to support Windows. script: already makes that support difficult, and shell injection can make this even worse. Let's be aware of the tradeoffs at least.

If this seems worth exploring, I can propose a TEP.