Trigger Schema Generated Tool

[SpiritZhou]

Generating trigger metadata schema according to new declarative scaler configuration, which can be used for validation or other related improvement.

Input:
make generate-scaler-schemas [--keda-version][--scalers-builder-file][--scalers-files-dir][--specify-scaler][--output-file-path]

Output:
scaler-metadata-schemas.yaml

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Relates to # #6345

[JorTurFer]

This PR is simply awesome! Could I suggest generating the output also as json as add a verification step during the CI to verify that the generated schemas are up to date?

[JorTurFer]

This PR is simply awesome! Could I suggest generating the output also as json as add a verification step during the CI to verify that the generated schemas are up-to-date?

And probably we want to pull the schema during the release too, using the specific version of the release

[SpiritZhou]

Sure, will add json as one more output file formate.

[zroubalik]

Great stuff!

Minor improvements/suggestions:

1. change the ouptup filename from scaler-metadata-schemas to scalers-metadata-schema
2. store the schema in schema/generated
3. regenerate the schema as part of the other generation stuff (probalby build step in the Makefile)
4. add a verification step to make sure schema is up to data (similar like it is done for clientset)
5. let's produce versioned schema file in the release pipeline named scalers-metadata-schema-v$KEDA_VERSION.json/yaml

[JorTurFer]

My point about generating the schema for the release was more related with generating it during the release and pushing it to the release itself as we do with manifests ->

keda/.github/workflows/release-build.yml

Lines 122 to 132 in 26a9cb8

	# Upload CRD deployment YAML file to GitHub release
	- name: Upload Deployment YAML file
	id: upload-crd-deployment-yaml
	uses: actions/upload-release-asset@e8f9f06c4b078e705bd2ea027f0926603fc9b4d5 # v1
	env:
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	with:
	upload_url: https://uploads.github.com/repos/kedacore/keda/releases/${{ steps.get-release-info.outputs.id }}/assets?name=keda-${{ steps.get_version.outputs.VERSION }}-crds.yaml
	asset_path: keda-${{ steps.get_version.outputs.VERSION }}-crds.yaml
	asset_name: keda-${{ steps.get_version.outputs.VERSION }}-crds.yaml
	asset_content_type: application/x-yaml

Having the file in the repo could be worth, but not versioned, just generated from main always, WDYT?

[SpiritZhou]

My point about generating the schema for the release was more related with generating it during the release and pushing it to the release itself as we do with manifests ->

keda/.github/workflows/release-build.yml

Lines 122 to 132 in 26a9cb8

	# Upload CRD deployment YAML file to GitHub release
	- name: Upload Deployment YAML file
	id: upload-crd-deployment-yaml
	uses: actions/upload-release-asset@e8f9f06c4b078e705bd2ea027f0926603fc9b4d5 # v1
	env:
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	with:
	upload_url: https://uploads.github.com/repos/kedacore/keda/releases/${{ steps.get-release-info.outputs.id }}/assets?name=keda-${{ steps.get_version.outputs.VERSION }}-crds.yaml
	asset_path: keda-${{ steps.get_version.outputs.VERSION }}-crds.yaml
	asset_name: keda-${{ steps.get_version.outputs.VERSION }}-crds.yaml
	asset_content_type: application/x-yaml

Having the file in the repo could be worth, but not versioned, just generated from main always, WDYT?

@JorTurFer I misunderstood your meaning before. Please correct me if I'm wrong:

1. Generate the versioned JSON and YAML schema files and push them to release assets.
2. Just keep the latest JSON and YAML schema files in the repo.

By the way, is there a way to test the release pipeline?

[JorTurFer]

@JorTurFer I misunderstood your meaning before. Please correct me if I'm wrong:

1. Generate the versioned JSON and YAML schema files and push them to release assets.
2. Just keep the latest JSON and YAML schema files in the repo.

Yeah, With this approach, if someone is using them, just downloading the files from the release will give a versionated files or checking out the tag (but publishing them as other release assets is worth IMHO)

By the way, is there a way to test the release pipeline?

Sadly, no. There isn't any good way to test that pipeline. The way that I used in the past is enabling workflows on my fork and triggering it there, but it's not the best either