#[non_exhaustive]pub struct CreateWorkflowVersionInput {Show 21 fields
pub workflow_id: Option<String>,
pub version_name: Option<String>,
pub definition_zip: Option<Blob>,
pub definition_uri: Option<String>,
pub accelerators: Option<Accelerators>,
pub description: Option<String>,
pub engine: Option<WorkflowEngine>,
pub main: Option<String>,
pub parameter_template: Option<HashMap<String, WorkflowParameter>>,
pub request_id: Option<String>,
pub storage_type: Option<StorageType>,
pub storage_capacity: Option<i32>,
pub tags: Option<HashMap<String, String>>,
pub workflow_bucket_owner_id: Option<String>,
pub container_registry_map: Option<ContainerRegistryMap>,
pub container_registry_map_uri: Option<String>,
pub readme_markdown: Option<String>,
pub parameter_template_path: Option<String>,
pub readme_path: Option<String>,
pub definition_repository: Option<DefinitionRepository>,
pub readme_uri: Option<String>,
}Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.workflow_id: Option<String>The ID of the workflow where you are creating the new version. The workflowId is not the UUID.
version_name: Option<String>A name for the workflow version. Provide a version name that is unique for this workflow. You cannot change the name after HealthOmics creates the version.
The version name must start with a letter or number and it can include upper-case and lower-case letters, numbers, hyphens, periods and underscores. The maximum length is 64 characters. You can use a simple naming scheme, such as version1, version2, version3. You can also match your workflow versions with your own internal versioning conventions, such as 2.7.0, 2.7.1, 2.7.2.
definition_zip: Option<Blob>A ZIP archive containing the main workflow definition file and dependencies that it imports for this workflow version. You can use a file with a ://fileb prefix instead of the Base64 string. For more information, see Workflow definition requirements in the Amazon Web Services HealthOmics User Guide.
definition_uri: Option<String>The S3 URI of a definition for this workflow version. The S3 bucket must be in the same region as this workflow version.
accelerators: Option<Accelerators>The computational accelerator for this workflow version.
description: Option<String>A description for this workflow version.
engine: Option<WorkflowEngine>The workflow engine for this workflow version. This is only required if you have workflow definition files from more than one engine in your zip file. Otherwise, the service can detect the engine automatically from your workflow definition.
main: Option<String>The path of the main definition file for this workflow version. This parameter is not required if the ZIP archive contains only one workflow definition file, or if the main definition file is named “main”. An example path is: workflow-definition/main-file.wdl.
parameter_template: Option<HashMap<String, WorkflowParameter>>A parameter template for this workflow version. If this field is blank, Amazon Web Services HealthOmics will automatically parse the parameter template values from your workflow definition file. To override these service generated default values, provide a parameter template. To view an example of a parameter template, see Parameter template files in the Amazon Web Services HealthOmics User Guide.
request_id: Option<String>An idempotency token to ensure that duplicate workflows are not created when Amazon Web Services HealthOmics submits retry requests.
storage_type: Option<StorageType>The default storage type for runs that use this workflow version. The storageType can be overridden at run time. DYNAMIC storage dynamically scales the storage up or down, based on file system utilization. STATIC storage allocates a fixed amount of storage. For more information about dynamic and static storage types, see Run storage types in the Amazon Web Services HealthOmics User Guide.
storage_capacity: Option<i32>The default static storage capacity (in gibibytes) for runs that use this workflow version. The storageCapacity can be overwritten at run time. The storage capacity is not required for runs with a DYNAMIC storage type.
Tags for this workflow version. You can define up to 50 tags for the workflow. For more information, see Adding a tag in the Amazon Web Services HealthOmics User Guide.
workflow_bucket_owner_id: Option<String>Amazon Web Services Id of the owner of the S3 bucket that contains the workflow definition. You need to specify this parameter if your account is not the bucket owner.
container_registry_map: Option<ContainerRegistryMap>(Optional) Use a container registry map to specify mappings between the ECR private repository and one or more upstream registries. For more information, see Container images in the Amazon Web Services HealthOmics User Guide.
container_registry_map_uri: Option<String>(Optional) URI of the S3 location for the registry mapping file.
readme_markdown: Option<String>The markdown content for the workflow version's README file. This provides documentation and usage information for users of this specific workflow version.
parameter_template_path: Option<String>The path to the workflow version parameter template JSON file within the repository. This file defines the input parameters for runs that use this workflow version. If not specified, the workflow version will be created without a parameter template.
readme_path: Option<String>The path to the workflow version README markdown file within the repository. This file provides documentation and usage information for the workflow. If not specified, the README.md file from the root directory of the repository will be used.
definition_repository: Option<DefinitionRepository>The repository information for the workflow version definition. This allows you to source your workflow version definition directly from a code repository.
readme_uri: Option<String>The S3 URI of the README file for the workflow version. This file provides documentation and usage information for the workflow version. Requirements include:
-
The S3 URI must begin with
s3://USER-OWNED-BUCKET/ -
The requester must have access to the S3 bucket and object.
-
The max README content length is 500 KiB.
Implementations§
Source§impl CreateWorkflowVersionInput
impl CreateWorkflowVersionInput
Sourcepub fn workflow_id(&self) -> Option<&str>
pub fn workflow_id(&self) -> Option<&str>
The ID of the workflow where you are creating the new version. The workflowId is not the UUID.
Sourcepub fn version_name(&self) -> Option<&str>
pub fn version_name(&self) -> Option<&str>
A name for the workflow version. Provide a version name that is unique for this workflow. You cannot change the name after HealthOmics creates the version.
The version name must start with a letter or number and it can include upper-case and lower-case letters, numbers, hyphens, periods and underscores. The maximum length is 64 characters. You can use a simple naming scheme, such as version1, version2, version3. You can also match your workflow versions with your own internal versioning conventions, such as 2.7.0, 2.7.1, 2.7.2.
Sourcepub fn definition_zip(&self) -> Option<&Blob>
pub fn definition_zip(&self) -> Option<&Blob>
A ZIP archive containing the main workflow definition file and dependencies that it imports for this workflow version. You can use a file with a ://fileb prefix instead of the Base64 string. For more information, see Workflow definition requirements in the Amazon Web Services HealthOmics User Guide.
Sourcepub fn definition_uri(&self) -> Option<&str>
pub fn definition_uri(&self) -> Option<&str>
The S3 URI of a definition for this workflow version. The S3 bucket must be in the same region as this workflow version.
Sourcepub fn accelerators(&self) -> Option<&Accelerators>
pub fn accelerators(&self) -> Option<&Accelerators>
The computational accelerator for this workflow version.
Sourcepub fn description(&self) -> Option<&str>
pub fn description(&self) -> Option<&str>
A description for this workflow version.
Sourcepub fn engine(&self) -> Option<&WorkflowEngine>
pub fn engine(&self) -> Option<&WorkflowEngine>
The workflow engine for this workflow version. This is only required if you have workflow definition files from more than one engine in your zip file. Otherwise, the service can detect the engine automatically from your workflow definition.
Sourcepub fn main(&self) -> Option<&str>
pub fn main(&self) -> Option<&str>
The path of the main definition file for this workflow version. This parameter is not required if the ZIP archive contains only one workflow definition file, or if the main definition file is named “main”. An example path is: workflow-definition/main-file.wdl.
Sourcepub fn parameter_template(&self) -> Option<&HashMap<String, WorkflowParameter>>
pub fn parameter_template(&self) -> Option<&HashMap<String, WorkflowParameter>>
A parameter template for this workflow version. If this field is blank, Amazon Web Services HealthOmics will automatically parse the parameter template values from your workflow definition file. To override these service generated default values, provide a parameter template. To view an example of a parameter template, see Parameter template files in the Amazon Web Services HealthOmics User Guide.
Sourcepub fn request_id(&self) -> Option<&str>
pub fn request_id(&self) -> Option<&str>
An idempotency token to ensure that duplicate workflows are not created when Amazon Web Services HealthOmics submits retry requests.
Sourcepub fn storage_type(&self) -> Option<&StorageType>
pub fn storage_type(&self) -> Option<&StorageType>
The default storage type for runs that use this workflow version. The storageType can be overridden at run time. DYNAMIC storage dynamically scales the storage up or down, based on file system utilization. STATIC storage allocates a fixed amount of storage. For more information about dynamic and static storage types, see Run storage types in the Amazon Web Services HealthOmics User Guide.
Sourcepub fn storage_capacity(&self) -> Option<i32>
pub fn storage_capacity(&self) -> Option<i32>
The default static storage capacity (in gibibytes) for runs that use this workflow version. The storageCapacity can be overwritten at run time. The storage capacity is not required for runs with a DYNAMIC storage type.
Tags for this workflow version. You can define up to 50 tags for the workflow. For more information, see Adding a tag in the Amazon Web Services HealthOmics User Guide.
Sourcepub fn workflow_bucket_owner_id(&self) -> Option<&str>
pub fn workflow_bucket_owner_id(&self) -> Option<&str>
Amazon Web Services Id of the owner of the S3 bucket that contains the workflow definition. You need to specify this parameter if your account is not the bucket owner.
Sourcepub fn container_registry_map(&self) -> Option<&ContainerRegistryMap>
pub fn container_registry_map(&self) -> Option<&ContainerRegistryMap>
(Optional) Use a container registry map to specify mappings between the ECR private repository and one or more upstream registries. For more information, see Container images in the Amazon Web Services HealthOmics User Guide.
Sourcepub fn container_registry_map_uri(&self) -> Option<&str>
pub fn container_registry_map_uri(&self) -> Option<&str>
(Optional) URI of the S3 location for the registry mapping file.
Sourcepub fn readme_markdown(&self) -> Option<&str>
pub fn readme_markdown(&self) -> Option<&str>
The markdown content for the workflow version's README file. This provides documentation and usage information for users of this specific workflow version.
Sourcepub fn parameter_template_path(&self) -> Option<&str>
pub fn parameter_template_path(&self) -> Option<&str>
The path to the workflow version parameter template JSON file within the repository. This file defines the input parameters for runs that use this workflow version. If not specified, the workflow version will be created without a parameter template.
Sourcepub fn readme_path(&self) -> Option<&str>
pub fn readme_path(&self) -> Option<&str>
The path to the workflow version README markdown file within the repository. This file provides documentation and usage information for the workflow. If not specified, the README.md file from the root directory of the repository will be used.
Sourcepub fn definition_repository(&self) -> Option<&DefinitionRepository>
pub fn definition_repository(&self) -> Option<&DefinitionRepository>
The repository information for the workflow version definition. This allows you to source your workflow version definition directly from a code repository.
Sourcepub fn readme_uri(&self) -> Option<&str>
pub fn readme_uri(&self) -> Option<&str>
The S3 URI of the README file for the workflow version. This file provides documentation and usage information for the workflow version. Requirements include:
-
The S3 URI must begin with
s3://USER-OWNED-BUCKET/ -
The requester must have access to the S3 bucket and object.
-
The max README content length is 500 KiB.
Source§impl CreateWorkflowVersionInput
impl CreateWorkflowVersionInput
Sourcepub fn builder() -> CreateWorkflowVersionInputBuilder
pub fn builder() -> CreateWorkflowVersionInputBuilder
Creates a new builder-style object to manufacture CreateWorkflowVersionInput.
Trait Implementations§
Source§impl Clone for CreateWorkflowVersionInput
impl Clone for CreateWorkflowVersionInput
Source§fn clone(&self) -> CreateWorkflowVersionInput
fn clone(&self) -> CreateWorkflowVersionInput
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read moreSource§impl Debug for CreateWorkflowVersionInput
impl Debug for CreateWorkflowVersionInput
impl StructuralPartialEq for CreateWorkflowVersionInput
Auto Trait Implementations§
impl Freeze for CreateWorkflowVersionInput
impl RefUnwindSafe for CreateWorkflowVersionInput
impl Send for CreateWorkflowVersionInput
impl Sync for CreateWorkflowVersionInput
impl Unpin for CreateWorkflowVersionInput
impl UnwindSafe for CreateWorkflowVersionInput
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left is true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left(&self) returns true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read moreSource§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the foreground set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red() and
green(), which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg():
use yansi::{Paint, Color};
painted.fg(Color::White);Set foreground color to white using white().
use yansi::Paint;
painted.white();Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self with the background set to
value.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red() and
on_green(), which have the same functionality but
are pithier.
§Example
Set background color to red using fg():
use yansi::{Paint, Color};
painted.bg(Color::Red);Set background color to red using on_red().
use yansi::Paint;
painted.on_red();Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute value.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold() and
underline(), which have the same functionality
but are pithier.
§Example
Make text bold using attr():
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);Make text bold using using bold().
use yansi::Paint;
painted.bold();Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi Quirk value.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask() and
wrap(), which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk():
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);Enable wrapping using wrap().
use yansi::Paint;
painted.wrap();Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting() due to conflicts with Vec::clear().
The clear() method will be removed in a future release.Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted only when both stdout and stderr are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);