Simplify and validate release build-output action configuration

[msarahan]

Posted by Codex (GPT-5) on behalf of @msarahan. This pull request description is LLM-generated; readers should treat its content accordingly.

Summary

Simplify release-build-output-dispatch to accept one schema-validated config JSON object and make the action work reliably from both host and container jobs.

The action now:

• accepts artifact_type, component_id, output_directory, and any custom-producer package/artifact selection through one config input;
• derives artifact descriptors and package identity for standard Conda and wheel outputs;
• requires custom producers to provide explicit artifact descriptors and exactly one of inline package identity or a producer-created package_file;
• validates the complete configuration before inspecting build outputs and reports field-specific errors as GitHub Actions annotations;
• resolves its implementation relative to the checked-out action, including the host/container workspace-path translation needed by container jobs;
• fixes the companion filenames as release-build-output.json and release-build-metadata.json, then uploads them with collected evidence as release-build-output-<source-artifact-name>; and
• removes the redundant nested release-build-output/action.yml entry point.

Why

The previous interface exposed many related scalar inputs and allowed combinations that only failed later during materialization. It also checked out shared-actions and invoked a nested local action, which could resolve to a host-only path from a container job. A single discriminated JSON object gives standard and custom producers one explicit contract, while schema and runtime validation provide actionable failures early in the pipeline.

[jameslamb]

I did my best to review this.

My read is that this replaces a bunch of individual arguments with:

• automatically calculating some of the values
• allowing a few more values only needed in specific cases (like cuVS Java builds) to be passed in as a single dictionary via this new config: argument

At a surface level that sounds good to me! Less opportunity for misconfiguration across the repos, easier to change the behavior in the future.

My comments in this PR are light, but see my review on rapidsai/shared-workflows#609 ... I think documentation (ideally written by a human) in the release-build-output/ directory would be really helpful for folks to understand why this exists and what it does. I looked through the code, logs, and output from the testing PRs (rapidsai/dask-cuda#1672, rapidsai/nx-cugraph#274, NVIDIA/cuvs#2400) and think I have a picture of that, but I personally would find it hard to modify this setup if a new requirement came in.

[jameslamb]

Suggested change

	skip: [actionlint-docker, release-build-output-config]
	# why skip these in pre-commit.ci?
	#
	# * 'actionlint-docker': needs docker
	# * 'release-build-output-config': need 'jq'
	#
	# There are covered in other CI jobs where we have more control over the runtime evnvironment.
	#
	skip: [actionlint-docker, release-build-output-config]

This comment is really verbose, overly-specific, and only applies to release-build-output-config even though its placement makes it looks like it applies to everything in skip:. Would you consider something like this suggestion?

[jameslamb]

Suggested change

	https://github.com/rapidsai/shared-actions/blob/main/release-build-output/config.schema.json
	JSON string with configuration for this action. Schema and field documentation:
	https://github.com/rapidsai/shared-actions/blob/main/release-build-output/config.schema.json

I don't think repeating the literal field names and the implementation detail "... and package identity when artifact_type is custom" is helpful. Let's simplify this and redirect back to the schema.

[jameslamb]

How do I figure out a value for this?

Do I generate a UUID and provide my own? Is this auto-generated by the code?

That type of detail would be helpful.