fix: Make conda package support multiple python versions #2227

[marek-mihok]

The PR fulfills these requirements: (check all the apply)

• [x] It's submitted to the main branch.
• [x] When resolving a specific issue, it's referenced in the PR's title (e.g. feat: Add a button #xxx, where "xxx" is the issue number).
• [x] When resolving a specific issue, the PR description includes Closes #xxx, where "xxx" is the issue number.
• [ ] If changes were made to ui folder, unit tests (make test) still pass.
• [ ] New/updated tests are included

  ---

The problem was that the package only supports the version of python it was built in. It can be solved by specifying noarch: python inside meta.yaml conda config file. The result is the single platform independent package supporting multiple python versions.

Also update of the pipeline build action (amauryval/publish_conda_package_action) to version 2.0.3 is necessary, because it allows specifying noarch value as the Platforms parameter.

Closes #2227

[marek-mihok]

We probably want to sync publish conda step in release-wave with publish-conda job as well.

@mturoci what is it used for? Is it for cases when you want to publish conda without going through all release process? It has no runs yet.

Also is CondaDir: 'py/conda' in publish-conda.yml instead of CondaDir: 'py/h2o_wave/conda' intentional? And what exactly do you mean by "sync"?

[mturoci]

Is it for cases when you want to publish conda without going through all release process?

Yes.

is CondaDir: 'py/conda' in publish-conda.yml instead of CondaDir: 'py/h2o_wave/conda' intentional?

Probably not. Seems like a leftover, but better check.

And what exactly do you mean by "sync"?

They should be the same. No matter which workflow I use, I want the output to be identical.

[marek-mihok]

@mturoci synced. Can we try to run publish-conda separately first to prevent release-wave from potential failing?