Class StartTaskArgs.Builder
- java.lang.Object
-
- com.pulumi.azurenative.batch.inputs.StartTaskArgs.Builder
-
- Enclosing class:
- StartTaskArgs
public static final class StartTaskArgs.Builder extends java.lang.Object
-
-
Constructor Summary
Constructors Constructor Description Builder()
Builder(StartTaskArgs defaults)
-
Method Summary
-
-
-
Constructor Detail
-
Builder
public Builder()
-
Builder
public Builder(StartTaskArgs defaults)
-
-
Method Detail
-
commandLine
public StartTaskArgs.Builder commandLine(@Nullable com.pulumi.core.Output<java.lang.String> commandLine)
- Parameters:
commandLine
- The command line does not run under a shell, and therefore cannot take advantage of shell features such as environment variable expansion. If you want to take advantage of such features, you should invoke the shell in the command line, for example using "cmd /c MyCommand" in Windows or "/bin/sh -c MyCommand" in Linux. Required if any other properties of the startTask are specified.- Returns:
- builder
-
commandLine
public StartTaskArgs.Builder commandLine(java.lang.String commandLine)
- Parameters:
commandLine
- The command line does not run under a shell, and therefore cannot take advantage of shell features such as environment variable expansion. If you want to take advantage of such features, you should invoke the shell in the command line, for example using "cmd /c MyCommand" in Windows or "/bin/sh -c MyCommand" in Linux. Required if any other properties of the startTask are specified.- Returns:
- builder
-
containerSettings
public StartTaskArgs.Builder containerSettings(@Nullable com.pulumi.core.Output<TaskContainerSettingsArgs> containerSettings)
- Parameters:
containerSettings
- When this is specified, all directories recursively below the AZ_BATCH_NODE_ROOT_DIR (the root of Azure Batch directories on the node) are mapped into the container, all task environment variables are mapped into the container, and the task command line is executed in the container.- Returns:
- builder
-
containerSettings
public StartTaskArgs.Builder containerSettings(TaskContainerSettingsArgs containerSettings)
- Parameters:
containerSettings
- When this is specified, all directories recursively below the AZ_BATCH_NODE_ROOT_DIR (the root of Azure Batch directories on the node) are mapped into the container, all task environment variables are mapped into the container, and the task command line is executed in the container.- Returns:
- builder
-
environmentSettings
public StartTaskArgs.Builder environmentSettings(@Nullable com.pulumi.core.Output<java.util.List<EnvironmentSettingArgs>> environmentSettings)
-
environmentSettings
public StartTaskArgs.Builder environmentSettings(java.util.List<EnvironmentSettingArgs> environmentSettings)
-
environmentSettings
public StartTaskArgs.Builder environmentSettings(EnvironmentSettingArgs... environmentSettings)
-
maxTaskRetryCount
public StartTaskArgs.Builder maxTaskRetryCount(@Nullable com.pulumi.core.Output<java.lang.Integer> maxTaskRetryCount)
- Parameters:
maxTaskRetryCount
- The Batch service retries a task if its exit code is nonzero. Note that this value specifically controls the number of retries. The Batch service will try the task once, and may then retry up to this limit. For example, if the maximum retry count is 3, Batch tries the task up to 4 times (one initial try and 3 retries). If the maximum retry count is 0, the Batch service does not retry the task. If the maximum retry count is -1, the Batch service retries the task without limit. Default is 0.- Returns:
- builder
-
maxTaskRetryCount
public StartTaskArgs.Builder maxTaskRetryCount(java.lang.Integer maxTaskRetryCount)
- Parameters:
maxTaskRetryCount
- The Batch service retries a task if its exit code is nonzero. Note that this value specifically controls the number of retries. The Batch service will try the task once, and may then retry up to this limit. For example, if the maximum retry count is 3, Batch tries the task up to 4 times (one initial try and 3 retries). If the maximum retry count is 0, the Batch service does not retry the task. If the maximum retry count is -1, the Batch service retries the task without limit. Default is 0.- Returns:
- builder
-
resourceFiles
public StartTaskArgs.Builder resourceFiles(@Nullable com.pulumi.core.Output<java.util.List<ResourceFileArgs>> resourceFiles)
-
resourceFiles
public StartTaskArgs.Builder resourceFiles(java.util.List<ResourceFileArgs> resourceFiles)
-
resourceFiles
public StartTaskArgs.Builder resourceFiles(ResourceFileArgs... resourceFiles)
-
userIdentity
public StartTaskArgs.Builder userIdentity(@Nullable com.pulumi.core.Output<UserIdentityArgs> userIdentity)
- Parameters:
userIdentity
- If omitted, the task runs as a non-administrative user unique to the task.- Returns:
- builder
-
userIdentity
public StartTaskArgs.Builder userIdentity(UserIdentityArgs userIdentity)
- Parameters:
userIdentity
- If omitted, the task runs as a non-administrative user unique to the task.- Returns:
- builder
-
waitForSuccess
public StartTaskArgs.Builder waitForSuccess(@Nullable com.pulumi.core.Output<java.lang.Boolean> waitForSuccess)
- Parameters:
waitForSuccess
- If true and the start task fails on a compute node, the Batch service retries the start task up to its maximum retry count (maxTaskRetryCount). If the task has still not completed successfully after all retries, then the Batch service marks the compute node unusable, and will not schedule tasks to it. This condition can be detected via the node state and scheduling error detail. If false, the Batch service will not wait for the start task to complete. In this case, other tasks can start executing on the compute node while the start task is still running; and even if the start task fails, new tasks will continue to be scheduled on the node. The default is true.- Returns:
- builder
-
waitForSuccess
public StartTaskArgs.Builder waitForSuccess(java.lang.Boolean waitForSuccess)
- Parameters:
waitForSuccess
- If true and the start task fails on a compute node, the Batch service retries the start task up to its maximum retry count (maxTaskRetryCount). If the task has still not completed successfully after all retries, then the Batch service marks the compute node unusable, and will not schedule tasks to it. This condition can be detected via the node state and scheduling error detail. If false, the Batch service will not wait for the start task to complete. In this case, other tasks can start executing on the compute node while the start task is still running; and even if the start task fails, new tasks will continue to be scheduled on the node. The default is true.- Returns:
- builder
-
build
public StartTaskArgs build()
-
-