added tes-autogenerated code for all the models

lib/src/TES/models/mod.rs

@@ -0,0 +1,34 @@
+pub mod service;
+pub use self::service::Service;
+pub mod service_organization;
+pub use self::service_organization::ServiceOrganization;
+pub mod service_type;
+pub use self::service_type::ServiceType;
+pub mod tes_create_task_response;
+pub use self::tes_create_task_response::TesCreateTaskResponse;
+pub mod tes_executor;
+pub use self::tes_executor::TesExecutor;
+pub mod tes_executor_log;
+pub use self::tes_executor_log::TesExecutorLog;
+pub mod tes_file_type;
+pub use self::tes_file_type::TesFileType;
+pub mod tes_input;
+pub use self::tes_input::TesInput;
+pub mod tes_list_tasks_response;
+pub use self::tes_list_tasks_response::TesListTasksResponse;
+pub mod tes_output;
+pub use self::tes_output::TesOutput;
+pub mod tes_output_file_log;
+pub use self::tes_output_file_log::TesOutputFileLog;
+pub mod tes_resources;
+pub use self::tes_resources::TesResources;
+pub mod tes_service_info;
+pub use self::tes_service_info::TesServiceInfo;
+pub mod tes_service_type;
+pub use self::tes_service_type::TesServiceType;
+pub mod tes_state;
+pub use self::tes_state::TesState;
+pub mod tes_task;
+pub use self::tes_task::TesTask;
+pub mod tes_task_log;
+pub use self::tes_task_log::TesTaskLog;

lib/src/TES/models/service.rs

@@ -0,0 +1,67 @@
+/*
+ * Task Execution Service
+ *
+ * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata.  TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include:    - Deploying existing workflow engines on new infrastructure. Workflow engines   such as CWL-Tes and Cromwell have extentions for using TES. This will allow   a system engineer to deploy them onto a new infrastructure using a job scheduling   system not previously supported by the engine.    - Developing a custom workflow management system. This API provides a common   interface to asynchronous batch processing capabilities. A developer can write   new tools against this interface and expect them to work using a variety of   backend solutions that all support the same specification.   ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers.  If authentication is required, we recommend that TES implementations use an OAuth2  bearer token, although they can choose other mechanisms if appropriate.  Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. 
+ *
+ * The version of the OpenAPI document: 1.1.0
+ * 
+ * Generated by: https://openapi-generator.tech
+ */
+
+use crate::models;
+
+/// Service : GA4GH service
+#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
+pub struct Service {
+    /// Unique ID of this service. Reverse domain name notation is recommended, though not required. The identifier should attempt to be globally unique so it can be used in downstream aggregator services e.g. Service Registry.
+    #[serde(rename = "id")]
+    pub id: String,
+    /// Name of this service. Should be human readable.
+    #[serde(rename = "name")]
+    pub name: String,
+    #[serde(rename = "type")]
+    pub r#type: Box<models::ServiceType>,
+    /// Description of the service. Should be human readable and provide information about the service.
+    #[serde(rename = "description", skip_serializing_if = "Option::is_none")]
+    pub description: Option<String>,
+    #[serde(rename = "organization")]
+    pub organization: Box<models::ServiceOrganization>,
+    /// URL of the contact for the provider of this service, e.g. a link to a contact form (RFC 3986 format), or an email (RFC 2368 format).
+    #[serde(rename = "contactUrl", skip_serializing_if = "Option::is_none")]
+    pub contact_url: Option<String>,
+    /// URL of the documentation of this service (RFC 3986 format). This should help someone learn how to use your service, including any specifics required to access data, e.g. authentication.
+    #[serde(rename = "documentationUrl", skip_serializing_if = "Option::is_none")]
+    pub documentation_url: Option<String>,
+    /// Timestamp describing when the service was first deployed and available (RFC 3339 format)
+    #[serde(rename = "createdAt", skip_serializing_if = "Option::is_none")]
+    pub created_at: Option<String>,
+    /// Timestamp describing when the service was last updated (RFC 3339 format)
+    #[serde(rename = "updatedAt", skip_serializing_if = "Option::is_none")]
+    pub updated_at: Option<String>,
+    /// Environment the service is running in. Use this to distinguish between production, development and testing/staging deployments. Suggested values are prod, test, dev, staging. However this is advised and not enforced.
+    #[serde(rename = "environment", skip_serializing_if = "Option::is_none")]
+    pub environment: Option<String>,
+    /// Version of the service being described. Semantic versioning is recommended, but other identifiers, such as dates or commit hashes, are also allowed. The version should be changed whenever the service is updated.
+    #[serde(rename = "version")]
+    pub version: String,
+}
+
+impl Service {
+    /// GA4GH service
+    pub fn new(id: String, name: String, r#type: models::ServiceType, organization: models::ServiceOrganization, version: String) -> Service {
+        Service {
+            id,
+            name,
+            r#type: Box::new(r#type),
+            description: None,
+            organization: Box::new(organization),
+            contact_url: None,
+            documentation_url: None,
+            created_at: None,
+            updated_at: None,
+            environment: None,
+            version,
+        }
+    }
+}
+

lib/src/TES/models/service_organization.rs

@@ -0,0 +1,33 @@
+/*
+ * Task Execution Service
+ *
+ * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata.  TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include:    - Deploying existing workflow engines on new infrastructure. Workflow engines   such as CWL-Tes and Cromwell have extentions for using TES. This will allow   a system engineer to deploy them onto a new infrastructure using a job scheduling   system not previously supported by the engine.    - Developing a custom workflow management system. This API provides a common   interface to asynchronous batch processing capabilities. A developer can write   new tools against this interface and expect them to work using a variety of   backend solutions that all support the same specification.   ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers.  If authentication is required, we recommend that TES implementations use an OAuth2  bearer token, although they can choose other mechanisms if appropriate.  Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. 
+ *
+ * The version of the OpenAPI document: 1.1.0
+ * 
+ * Generated by: https://openapi-generator.tech
+ */
+
+use crate::models;
+
+/// ServiceOrganization : Organization providing the service
+#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
+pub struct ServiceOrganization {
+    /// Name of the organization responsible for the service
+    #[serde(rename = "name")]
+    pub name: String,
+    /// URL of the website of the organization (RFC 3986 format)
+    #[serde(rename = "url")]
+    pub url: String,
+}
+
+impl ServiceOrganization {
+    /// Organization providing the service
+    pub fn new(name: String, url: String) -> ServiceOrganization {
+        ServiceOrganization {
+            name,
+            url,
+        }
+    }
+}
+

lib/src/TES/models/service_type.rs

@@ -0,0 +1,37 @@
+/*
+ * Task Execution Service
+ *
+ * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata.  TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include:    - Deploying existing workflow engines on new infrastructure. Workflow engines   such as CWL-Tes and Cromwell have extentions for using TES. This will allow   a system engineer to deploy them onto a new infrastructure using a job scheduling   system not previously supported by the engine.    - Developing a custom workflow management system. This API provides a common   interface to asynchronous batch processing capabilities. A developer can write   new tools against this interface and expect them to work using a variety of   backend solutions that all support the same specification.   ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers.  If authentication is required, we recommend that TES implementations use an OAuth2  bearer token, although they can choose other mechanisms if appropriate.  Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. 
+ *
+ * The version of the OpenAPI document: 1.1.0
+ * 
+ * Generated by: https://openapi-generator.tech
+ */
+
+use crate::models;
+
+/// ServiceType : Type of a GA4GH service
+#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
+pub struct ServiceType {
+    /// Namespace in reverse domain name format. Use `org.ga4gh` for implementations compliant with official GA4GH specifications. For services with custom APIs not standardized by GA4GH, or implementations diverging from official GA4GH specifications, use a different namespace (e.g. your organization's reverse domain name).
+    #[serde(rename = "group")]
+    pub group: String,
+    /// Name of the API or GA4GH specification implemented. Official GA4GH types should be assigned as part of standards approval process. Custom artifacts are supported.
+    #[serde(rename = "artifact")]
+    pub artifact: String,
+    /// Version of the API or specification. GA4GH specifications use semantic versioning.
+    #[serde(rename = "version")]
+    pub version: String,
+}
+
+impl ServiceType {
+    /// Type of a GA4GH service
+    pub fn new(group: String, artifact: String, version: String) -> ServiceType {
+        ServiceType {
+            group,
+            artifact,
+            version,
+        }
+    }
+}
+

lib/src/TES/models/tes_create_task_response.rs

@@ -0,0 +1,29 @@
+/*
+ * Task Execution Service
+ *
+ * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata.  TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include:    - Deploying existing workflow engines on new infrastructure. Workflow engines   such as CWL-Tes and Cromwell have extentions for using TES. This will allow   a system engineer to deploy them onto a new infrastructure using a job scheduling   system not previously supported by the engine.    - Developing a custom workflow management system. This API provides a common   interface to asynchronous batch processing capabilities. A developer can write   new tools against this interface and expect them to work using a variety of   backend solutions that all support the same specification.   ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers.  If authentication is required, we recommend that TES implementations use an OAuth2  bearer token, although they can choose other mechanisms if appropriate.  Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. 
+ *
+ * The version of the OpenAPI document: 1.1.0
+ * 
+ * Generated by: https://openapi-generator.tech
+ */
+
+use crate::models;
+
+/// TesCreateTaskResponse : CreateTaskResponse describes a response from the CreateTask endpoint. It will include the task ID that can be used to look up the status of the job.
+#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
+pub struct TesCreateTaskResponse {
+    /// Task identifier assigned by the server.
+    #[serde(rename = "id")]
+    pub id: String,
+}
+
+impl TesCreateTaskResponse {
+    /// CreateTaskResponse describes a response from the CreateTask endpoint. It will include the task ID that can be used to look up the status of the job.
+    pub fn new(id: String) -> TesCreateTaskResponse {
+        TesCreateTaskResponse {
+            id,
+        }
+    }
+}
+