Organization of [cluster] build strategies

[sbose78]

I wish to start the discussion on what the long term organization of build strategy samples would look like. At the moment, we have 6 top level strategies, with 3 additional strategies nested under s2i, buildpacks and kaniko.

In the long-term, I do not wish to move the top-level strategies out of this repo however I do wonder if we should consider an alternative structure for the additional nested strategy samples which deal with, in order to avoid a proliferation of strategies ?

• A different image for the build technology ( Buildpacks heroku v/s Buildpacks paketo, s2i community v/s s2i Red Hat )
• A combination of using the build technology with other tools ( kaniko with trivy )

I find these additional strategies extremely useful, and therefore whatever we do shouldn't compromise on the discoverability of these strategies.

[blairdrummond]

Hey @sbose78 ! I have a draft of the thing I'm working on (it's not ready yet),

apiVersion: shipwright.io/v1alpha1
kind: ClusterBuildStrategy
metadata:
  name: azure-acr
spec:
  #parameters:
  #- name: registry
  #  description: "The Azure registry to push to"
  #- name: platform
  #  description: "The platform to build for"
  #  default: linux
  buildSteps:
    - name: build
      image: mcr.microsoft.com/azure-cli:2.9.1
      workingDir: $(params.shp-source-root)
      securityContext:
        runAsUser: 0
      env:
        - name: AWS_ACCESS_KEY_ID
          value: NOT_SET
        - name: AWS_SECRET_KEY
          value: NOT_SET
        - name: DOCKER_CONFIG
          value: /root/.docker/
        - name: HOME
          value: /tekton/home
      command: 
        - /bin/sh
        - -c
        - |
           /usr/local/bin/az acr login --name bdrummond
           /usr/local/bin/az acr build -f $(build.dockerfile) --image=$(build.output.image) --registry=bdrummond $(params.shp-source-context)
        # - --platform=$(params.platform)
      resources:
        limits:
          cpu: 500m
          memory: 1Gi
        requests:
          cpu: 250m
          memory: 65Mi

Instead of building the images inside the cluster, I wanted to try writing strategies for out-of-cluster builds supported by cloud provider services. (In my org, this is to avoid the risks of building untrusted OCI images inside the cluster).

This poses a few issues though of course! I would still have a {unscanned,trivy} version for each of {az acr build,gcloud build, aws???}, but then I'm not sure how to organize them or provide e2e testing.