feat(wes): add support for the GA4GH WES API

[pavelnikonorov]

Description:

Enhance the GA4GH SDK and associated CLI by adding support for the GA4GH Workflow Execution Service (WES) API. This feature would enable users to interact with WES-compliant services, both programmatically (through the SDK) and via command-line commands (through the CLI).

We are targeting v1.1.0 of the WES specification. Please refer to the corresponding documentation and OpenAPI specification document.

Associated issues:

This issue is a meta issue requiring the following individual issues to be addressed.

• feat(wes): add models #49
• feat(wes): add SDK support #50
• feat(wes): add CLI support #51
• feat(wes): add Python bindings #52

---

Documentation Requirements:

Update CLI and SDK documentation with usage examples and configuration details for WES.

Testing Requirements:

Add integration tests for CLI commands and unit tests for SDK methods to confirm functionality and error handling.

Developer Notes:

Please get familiar with the SDK ServiceInfo and TES client implementations. Similarly, new client implementations including the WES client should leverage the Configuration struct (Rust term similar to C++ classes) and the Transport struct. This ensures consistent handling of configurations and communication across the SDK, maintaining architectural integrity and simplifying future maintenance and feature expansion.

To run code with additional debug output messages provided by debug!("[...]") macro:

RUST_LOG=debug cargo build 

To test the CLI commands:

RUST_LOG=debug cargo run [your-cli-command-parameter]

If your implementation requires additional modules (or crates in Rust terminology) add them to the ./lib/Cargo.toml for the SDK or to ./cli/Cargo.toml for the CLI.

[suecharo]

Thank you for creating the issue. (@pavelnikonorov , @uniqueg )

I have a few questions (as memo) at this stage:

• How should I manage PRs and code contributions?
  • Should fork this repository and submit PRs from my fork?
  • OR should I create branches directly in this repository as contributors?
• Regarding the WES 1.1.0 implementation, how should we approach integration testing?
  • It’s unclear if there is a WES implementation that fully adheres to WES 1.1.0.
  • A list of WES implementations here: https://github.com/ga4gh/workflow-execution-service-schemas/pull/219/files
  • Starter Kit WES currently supports WES 1.0.1.
  • Sapporo currently supports WES 1.1.0, but with some extensions.
    • For discussions on the extensions and modifications, the following may be useful:
      • Request to Add DELETE /runs/{run_id} Endpoint workflow-execution-service-schemas#218
      • Propose Enhancements from Sapporo WES 2.0.0 workflow-execution-service-schemas#220

[suecharo]

For integration testing of the TES part, using funnel and listing it as a requirement.

[uniqueg]

Hi @suecharo, some comments from my side:

• Our CI pipelines generally work best when PRs are created from feature branches. I have sent you an invite for joining the ELIXIR Cloud & AAI GitHub org. I have also described the general workflow in our contributor guidelines for the hackathon.
• You raise a valid point about WES 1.1.0. Perhaps it is best to use the Starter Kit implementation and use WES 1.0.1 for the SDK implementation. It should be easy enough to upgrade later on.

[suecharo]

It seems that the current implementation (such as models) does not include versioning. How should we handle this?
For example, should we organize it like ./lib/src/clients/wes/101 ?
(This probably requires a discussion with the whole team.)