#[non_exhaustive]pub struct CreateWorkflowInput {Show 18 fields
pub name: Option<String>,
pub description: Option<String>,
pub engine: Option<WorkflowEngine>,
pub definition_zip: Option<Blob>,
pub definition_uri: Option<String>,
pub main: Option<String>,
pub parameter_template: Option<HashMap<String, WorkflowParameter>>,
pub storage_capacity: Option<i32>,
pub tags: Option<HashMap<String, String>>,
pub request_id: Option<String>,
pub accelerators: Option<Accelerators>,
pub storage_type: Option<StorageType>,
pub readme_markdown: Option<String>,
pub parameter_template_path: Option<String>,
pub readme_path: Option<String>,
pub definition_repository: Option<DefinitionRepository>,
pub workflow_bucket_owner_id: Option<String>,
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.name: Option<String>Name (optional but highly recommended) for the workflow to locate relevant information in the CloudWatch logs and Amazon Web Services HealthOmics console.
description: Option<String>A description for the workflow.
engine: Option<WorkflowEngine>The workflow engine for the workflow. 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.
definition_zip: Option<Blob>A ZIP archive containing the main workflow definition file and dependencies that it imports for the workflow. 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 the workflow. The S3 bucket must be in the same region as the workflow.
main: Option<String>The path of the main definition file for the workflow. 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 the workflow. 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.
storage_capacity: Option<i32>The default static storage capacity (in gibibytes) for runs that use this workflow or 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 the workflow. 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.
request_id: Option<String>An idempotency token to ensure that duplicate workflows are not created when Amazon Web Services HealthOmics submits retry requests.
accelerators: Option<Accelerators>The computational accelerator specified to run the workflow.
storage_type: Option<StorageType>The default storage type for runs that use this workflow. 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.
readme_markdown: Option<String>The markdown content for the workflow's README file. This provides documentation and usage information for users of the workflow.
parameter_template_path: Option<String>The path to the workflow parameter template JSON file within the repository. This file defines the input parameters for runs that use this workflow. If not specified, the workflow will be created without a parameter template.
readme_path: Option<String>The path to the workflow 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 definition. This allows you to source your workflow definition directly from a code repository.
workflow_bucket_owner_id: Option<String>The Amazon Web Services account ID of the expected owner of the S3 bucket that contains the workflow definition. If not specified, the service skips the validation.
readme_uri: Option<String>The S3 URI of the README file for the workflow. This file provides documentation and usage information for the workflow. 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 CreateWorkflowInput
impl CreateWorkflowInput
Sourcepub fn name(&self) -> Option<&str>
pub fn name(&self) -> Option<&str>
Name (optional but highly recommended) for the workflow to locate relevant information in the CloudWatch logs and Amazon Web Services HealthOmics console.
Sourcepub fn description(&self) -> Option<&str>
pub fn description(&self) -> Option<&str>
A description for the workflow.
Sourcepub fn engine(&self) -> Option<&WorkflowEngine>
pub fn engine(&self) -> Option<&WorkflowEngine>
The workflow engine for the workflow. 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 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 the workflow. 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 the workflow. The S3 bucket must be in the same region as the workflow.
Sourcepub fn main(&self) -> Option<&str>
pub fn main(&self) -> Option<&str>
The path of the main definition file for the workflow. 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 the workflow. 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 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 or 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 the workflow. 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 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 accelerators(&self) -> Option<&Accelerators>
pub fn accelerators(&self) -> Option<&Accelerators>
The computational accelerator specified to run the workflow.
Sourcepub fn storage_type(&self) -> Option<&StorageType>
pub fn storage_type(&self) -> Option<&StorageType>
The default storage type for runs that use this workflow. 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 readme_markdown(&self) -> Option<&str>
pub fn readme_markdown(&self) -> Option<&str>
The markdown content for the workflow's README file. This provides documentation and usage information for users of the workflow.
Sourcepub fn parameter_template_path(&self) -> Option<&str>
pub fn parameter_template_path(&self) -> Option<&str>
The path to the workflow parameter template JSON file within the repository. This file defines the input parameters for runs that use this workflow. If not specified, the workflow 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 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 definition. This allows you to source your workflow definition directly from a code repository.
Sourcepub fn workflow_bucket_owner_id(&self) -> Option<&str>
pub fn workflow_bucket_owner_id(&self) -> Option<&str>
The Amazon Web Services account ID of the expected owner of the S3 bucket that contains the workflow definition. If not specified, the service skips the validation.
Sourcepub fn readme_uri(&self) -> Option<&str>
pub fn readme_uri(&self) -> Option<&str>
The S3 URI of the README file for the workflow. This file provides documentation and usage information for the workflow. 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 CreateWorkflowInput
impl CreateWorkflowInput
Sourcepub fn builder() -> CreateWorkflowInputBuilder
pub fn builder() -> CreateWorkflowInputBuilder
Creates a new builder-style object to manufacture CreateWorkflowInput.
Trait Implementations§
Source§impl Clone for CreateWorkflowInput
impl Clone for CreateWorkflowInput
Source§fn clone(&self) -> CreateWorkflowInput
fn clone(&self) -> CreateWorkflowInput
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read moreSource§impl Debug for CreateWorkflowInput
impl Debug for CreateWorkflowInput
Source§impl PartialEq for CreateWorkflowInput
impl PartialEq for CreateWorkflowInput
impl StructuralPartialEq for CreateWorkflowInput
Auto Trait Implementations§
impl Freeze for CreateWorkflowInput
impl RefUnwindSafe for CreateWorkflowInput
impl Send for CreateWorkflowInput
impl Sync for CreateWorkflowInput
impl Unpin for CreateWorkflowInput
impl UnwindSafe for CreateWorkflowInput
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);