🌱 hack: implement generator for prowjobs

[chrischdi]

What this PR does / why we need it:

Implements prowjob-gen a lightweight tool based on go-templates and a configuration file to template prowjob configuration across multiple branches.

Example usage (./../k8s.io/test-infra is the relativ path for me locally to the root of the test-infra directory):

TEST_INFRA_DIR=../../k8s.io/test-infra make generate-test-infra-prowjobs

Example output: kubernetes/test-infra#31581

One change to our configuration would be currently:

Our jobs upgrading to latest kubernetes (currently v1.30) had latest in their job names. With the current implementation those will use 1-30 instead.

Example:

• Before: periodic-cluster-api-e2e-workload-upgrade-1-29-latest-main
• After: periodic-cluster-api-e2e-workload-upgrade-1-29-1-30-main

Requires to merge the following to make mdlint happy:

• cluster-api: introduce prowjob-generator configuration and generate prowjobs kubernetes/test-infra#31581

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #9257

/area ci

[chrischdi]

/retest

[chrischdi]

 failed to get component source YAML from URL: failed to get https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.6.0/core-components.yaml: got status code 500

/retest

[chrischdi]

/retitle 🌱 [wip] hack: implement generator for prowjobs

[cprivitere]

Any concerns that we're bringing in a library that hasn't been updated since November of 2022? (github.com/Masterminds/sprig)

[chrischdi]

Any concerns that we're bringing in a library that hasn't been updated since November of 2022? (github.com/Masterminds/sprig)

Great point, I did not think about that.

We already use sprig in clusterclass / in our core go.mod file which is why I think this could be considered okay.

[cprivitere]

Any concerns that we're bringing in a library that hasn't been updated since November of 2022? (github.com/Masterminds/sprig)

Great point, I did not think about that.

We already use sprig in clusterclass / in our core go.mod file which is why I think this could be considered okay.

If the group already agrees it's ok, then I guess that's cool.

Was just a bit concerned given their go.mod is based on 1.13 and they're bringing in old versions of semver.

[chrischdi]

To add: happy to adjust / remove it if we consider it for it should not being used, definetly not a must. Some of the sprig functions may just make it more easy to write the templates.

[chrischdi]

Note: I removed sprig and replaced it by standard library functions.

One exception: I added a last function which returns the last element of an array or slice.

Also removed the other custom implemented functions.

[sbueringer]

First round of review. Will continue later

[fabriziopandini]

Overall lgtm, great to see this making progress!

[chrischdi]

@sbueringer PTAL

pending squash

[sbueringer]

Thx! Really nice

/lgtm

/assign @fabriziopandini

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 7add3fe4b7957b2e14925067896068fcde5d40ed

[sbueringer]

Thx!

/lgtm
/approve

/hold cancel

[sbueringer]

/hold

[sbueringer]

Sorry wrong tab wanted to approve the test-infra PR :D

/approve cancel

[sbueringer]

/hold cancel

[fabriziopandini]

Great job!
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fabriziopandini]

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