Update tekton by moving tasks to separate file

[AnnaZivkovic]

Update tekton files to match olm-operator-konflux-sample

https://github.com/konflux-ci/olm-operator-konflux-sample/blob/main/.tekton/multi-arch-build-pipeline.yaml#L79-L126

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from annazivkovic. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aleskandro]

(unrelated to the PR)

this sounds unsafe for a future where a Konflux cluster might run on another arch than the (correctly, but also just currently) assumed amd64 or even in the multi-arch compute possibility.

cc @jeffdyoung @arewm it would be nice if konflux makes it always explicit which architecture we are requesting instead of relying on the assumption that 'localhost' (konflux cluster) is amd64.

Maybe, the script that processes this array might inspect the cluster where the builds are going to run and check whether the platform is available in the cluster (local build0 or not (delegate the build to the multi-platform manager):

node_arches = $(oc get nodes -o jsonpath="{range .items[*]}{.status.nodeInfo.architecture}{'\n'}{end}" | sort | uniq)
for platform in platforms:
  if platform in node_arches:
    build_local(...)
  else:
    build_remote_platform_manager(...)

[arewm]

Yes, that is a limitation to the current implemenation. If you would prefer a targeted localhost, you can use linux/x86_64. https://github.com/redhat-appstudio/infra-deployments/blob/main/components/multi-platform-controller/production/stone-prd-rh01/host-config.yaml#L10

My desire was to change linux/amd64 to also be a local host, requiring users to explicitly specify whether they want a VM with something like linux-mlarge/amd64.

That would eventually mean that once we have multiple node pools, we might change linux/arm64 to be in-cluster, requiring users to explicitly request VMs again.

https://issues.redhat.com/browse/KONFLUX-4073 was the feature that I opened for this which has since been closed in favor of https://issues.redhat.com/browse/KONFLUX-6091.

[aleskandro]

However, in a more k8s/ocp/nonVM-native way, that desire can be solved by allowing to set the resource requests in the Build Tasks and by configuring the cluster autoscaler with machineset autoscalers that can fit different scenarios. Once a 'large' build is created, the cluster would create a Machine with the proper size to host the build (if needed).

[aleskandro]

Yes, that is a limitation to the current implemenation. If you would prefer a targeted localhost, you can use linux/x86_64. https://github.com/redhat-appstudio/infra-deployments/blob/main/components/multi-platform-controller/production/stone-prd-rh01/host-config.yaml#L10

This works and would allow us to delegate you about fixing the equivalence between localhost and amd64 :)

[Prashanth684]

However, in a more k8s/ocp/nonVM-native way, that desire can be solved by allowing to set the resource requests in the Build Tasks and by configuring the cluster autoscaler with machineset autoscalers

This would still not account for the case where the architecture is not supported by the platform, right?

[aleskandro]

It doesn't for now... But starting from the available arches is already a good step forward imho

[aleskandro]

Suggested change

	- localhost
	- linux/amd64

[aleskandro]

/retest

[openshift-ci]

@AnnaZivkovic: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[aleskandro]

/retest