#[non_exhaustive]pub struct ProjectEnvironment {
pub type: EnvironmentType,
pub image: String,
pub compute_type: ComputeType,
pub compute_configuration: Option<ComputeConfiguration>,
pub fleet: Option<ProjectFleet>,
pub environment_variables: Option<Vec<EnvironmentVariable>>,
pub privileged_mode: Option<bool>,
pub certificate: Option<String>,
pub registry_credential: Option<RegistryCredential>,
pub image_pull_credentials_type: Option<ImagePullCredentialsType>,
pub docker_server: Option<DockerServer>,
}
Expand description
Information about the build environment of the build project.
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.type: EnvironmentType
The type of build environment to use for related builds.
If you're using compute fleets during project creation, type
will be ignored.
For more information, see Build environment compute types in the CodeBuild user guide.
image: String
The image tag or image digest that identifies the Docker image to use for this build project. Use the following formats:
-
For an image tag:
. For example, in the Docker repository that CodeBuild uses to manage its Docker images, this would be/ : aws/codebuild/standard:4.0
. -
For an image digest:
. For example, to specify an image with the digest "sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf," use/ @
./ @sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
For more information, see Docker images provided by CodeBuild in the CodeBuild user guide.
compute_type: ComputeType
Information about the compute resources the build project uses. Available values include:
-
ATTRIBUTE_BASED_COMPUTE
: Specify the amount of vCPUs, memory, disk space, and the type of machine.If you use
ATTRIBUTE_BASED_COMPUTE
, you must define your attributes by usingcomputeConfiguration
. CodeBuild will select the cheapest instance that satisfies your specified attributes. For more information, see Reserved capacity environment types in the CodeBuild User Guide. -
BUILD_GENERAL1_SMALL
: Use up to 4 GiB memory and 2 vCPUs for builds. -
BUILD_GENERAL1_MEDIUM
: Use up to 8 GiB memory and 4 vCPUs for builds. -
BUILD_GENERAL1_LARGE
: Use up to 16 GiB memory and 8 vCPUs for builds, depending on your environment type. -
BUILD_GENERAL1_XLARGE
: Use up to 72 GiB memory and 36 vCPUs for builds, depending on your environment type. -
BUILD_GENERAL1_2XLARGE
: Use up to 144 GiB memory, 72 vCPUs, and 824 GB of SSD storage for builds. This compute type supports Docker images up to 100 GB uncompressed. -
BUILD_LAMBDA_1GB
: Use up to 1 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_2GB
: Use up to 2 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_4GB
: Use up to 4 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_8GB
: Use up to 8 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_10GB
: Use up to 10 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
.
If you use BUILD_GENERAL1_SMALL
:
-
For environment type
LINUX_CONTAINER
, you can use up to 4 GiB memory and 2 vCPUs for builds. -
For environment type
LINUX_GPU_CONTAINER
, you can use up to 16 GiB memory, 4 vCPUs, and 1 NVIDIA A10G Tensor Core GPU for builds. -
For environment type
ARM_CONTAINER
, you can use up to 4 GiB memory and 2 vCPUs on ARM-based processors for builds.
If you use BUILD_GENERAL1_LARGE
:
-
For environment type
LINUX_CONTAINER
, you can use up to 16 GiB memory and 8 vCPUs for builds. -
For environment type
LINUX_GPU_CONTAINER
, you can use up to 255 GiB memory, 32 vCPUs, and 4 NVIDIA Tesla V100 GPUs for builds. -
For environment type
ARM_CONTAINER
, you can use up to 16 GiB memory and 8 vCPUs on ARM-based processors for builds.
For more information, see On-demand environment types in the CodeBuild User Guide.
compute_configuration: Option<ComputeConfiguration>
The compute configuration of the build project. This is only required if computeType
is set to ATTRIBUTE_BASED_COMPUTE
.
fleet: Option<ProjectFleet>
A ProjectFleet object to use for this build project.
environment_variables: Option<Vec<EnvironmentVariable>>
A set of environment variables to make available to builds for this build project.
privileged_mode: Option<bool>
Enables running the Docker daemon inside a Docker container. Set to true only if the build project is used to build Docker images. Otherwise, a build that attempts to interact with the Docker daemon fails. The default setting is false
.
You can initialize the Docker daemon during the install phase of your build by adding one of the following sets of commands to the install phase of your buildspec file:
If the operating system's base image is Ubuntu Linux:
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://0.0.0.0:2375 --storage-driver=overlay&
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
If the operating system's base image is Alpine Linux and the previous command does not work, add the -t
argument to timeout
:
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://0.0.0.0:2375 --storage-driver=overlay&
- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"
certificate: Option<String>
The ARN of the Amazon S3 bucket, path prefix, and object key that contains the PEM-encoded certificate for the build project. For more information, see certificate in the CodeBuild User Guide.
registry_credential: Option<RegistryCredential>
The credentials for access to a private registry.
image_pull_credentials_type: Option<ImagePullCredentialsType>
The type of credentials CodeBuild uses to pull images in your build. There are two valid values:
-
CODEBUILD
specifies that CodeBuild uses its own credentials. This requires that you modify your ECR repository policy to trust CodeBuild service principal. -
SERVICE_ROLE
specifies that CodeBuild uses your build project's service role.
When you use a cross-account or private registry image, you must use SERVICE_ROLE credentials. When you use an CodeBuild curated image, you must use CODEBUILD credentials.
docker_server: Option<DockerServer>
A DockerServer object to use for this build project.
Implementations§
Source§impl ProjectEnvironment
impl ProjectEnvironment
Sourcepub fn type(&self) -> &EnvironmentType
pub fn type(&self) -> &EnvironmentType
The type of build environment to use for related builds.
If you're using compute fleets during project creation, type
will be ignored.
For more information, see Build environment compute types in the CodeBuild user guide.
Sourcepub fn image(&self) -> &str
pub fn image(&self) -> &str
The image tag or image digest that identifies the Docker image to use for this build project. Use the following formats:
-
For an image tag:
. For example, in the Docker repository that CodeBuild uses to manage its Docker images, this would be/ : aws/codebuild/standard:4.0
. -
For an image digest:
. For example, to specify an image with the digest "sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf," use/ @
./ @sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf
For more information, see Docker images provided by CodeBuild in the CodeBuild user guide.
Sourcepub fn compute_type(&self) -> &ComputeType
pub fn compute_type(&self) -> &ComputeType
Information about the compute resources the build project uses. Available values include:
-
ATTRIBUTE_BASED_COMPUTE
: Specify the amount of vCPUs, memory, disk space, and the type of machine.If you use
ATTRIBUTE_BASED_COMPUTE
, you must define your attributes by usingcomputeConfiguration
. CodeBuild will select the cheapest instance that satisfies your specified attributes. For more information, see Reserved capacity environment types in the CodeBuild User Guide. -
BUILD_GENERAL1_SMALL
: Use up to 4 GiB memory and 2 vCPUs for builds. -
BUILD_GENERAL1_MEDIUM
: Use up to 8 GiB memory and 4 vCPUs for builds. -
BUILD_GENERAL1_LARGE
: Use up to 16 GiB memory and 8 vCPUs for builds, depending on your environment type. -
BUILD_GENERAL1_XLARGE
: Use up to 72 GiB memory and 36 vCPUs for builds, depending on your environment type. -
BUILD_GENERAL1_2XLARGE
: Use up to 144 GiB memory, 72 vCPUs, and 824 GB of SSD storage for builds. This compute type supports Docker images up to 100 GB uncompressed. -
BUILD_LAMBDA_1GB
: Use up to 1 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_2GB
: Use up to 2 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_4GB
: Use up to 4 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_8GB
: Use up to 8 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
. -
BUILD_LAMBDA_10GB
: Use up to 10 GiB memory for builds. Only available for environment typeLINUX_LAMBDA_CONTAINER
andARM_LAMBDA_CONTAINER
.
If you use BUILD_GENERAL1_SMALL
:
-
For environment type
LINUX_CONTAINER
, you can use up to 4 GiB memory and 2 vCPUs for builds. -
For environment type
LINUX_GPU_CONTAINER
, you can use up to 16 GiB memory, 4 vCPUs, and 1 NVIDIA A10G Tensor Core GPU for builds. -
For environment type
ARM_CONTAINER
, you can use up to 4 GiB memory and 2 vCPUs on ARM-based processors for builds.
If you use BUILD_GENERAL1_LARGE
:
-
For environment type
LINUX_CONTAINER
, you can use up to 16 GiB memory and 8 vCPUs for builds. -
For environment type
LINUX_GPU_CONTAINER
, you can use up to 255 GiB memory, 32 vCPUs, and 4 NVIDIA Tesla V100 GPUs for builds. -
For environment type
ARM_CONTAINER
, you can use up to 16 GiB memory and 8 vCPUs on ARM-based processors for builds.
For more information, see On-demand environment types in the CodeBuild User Guide.
Sourcepub fn compute_configuration(&self) -> Option<&ComputeConfiguration>
pub fn compute_configuration(&self) -> Option<&ComputeConfiguration>
The compute configuration of the build project. This is only required if computeType
is set to ATTRIBUTE_BASED_COMPUTE
.
Sourcepub fn fleet(&self) -> Option<&ProjectFleet>
pub fn fleet(&self) -> Option<&ProjectFleet>
A ProjectFleet object to use for this build project.
Sourcepub fn environment_variables(&self) -> &[EnvironmentVariable]
pub fn environment_variables(&self) -> &[EnvironmentVariable]
A set of environment variables to make available to builds for this build project.
If no value was sent for this field, a default will be set. If you want to determine if no value was sent, use .environment_variables.is_none()
.
Sourcepub fn privileged_mode(&self) -> Option<bool>
pub fn privileged_mode(&self) -> Option<bool>
Enables running the Docker daemon inside a Docker container. Set to true only if the build project is used to build Docker images. Otherwise, a build that attempts to interact with the Docker daemon fails. The default setting is false
.
You can initialize the Docker daemon during the install phase of your build by adding one of the following sets of commands to the install phase of your buildspec file:
If the operating system's base image is Ubuntu Linux:
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://0.0.0.0:2375 --storage-driver=overlay&
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
If the operating system's base image is Alpine Linux and the previous command does not work, add the -t
argument to timeout
:
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://0.0.0.0:2375 --storage-driver=overlay&
- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"
Sourcepub fn certificate(&self) -> Option<&str>
pub fn certificate(&self) -> Option<&str>
The ARN of the Amazon S3 bucket, path prefix, and object key that contains the PEM-encoded certificate for the build project. For more information, see certificate in the CodeBuild User Guide.
Sourcepub fn registry_credential(&self) -> Option<&RegistryCredential>
pub fn registry_credential(&self) -> Option<&RegistryCredential>
The credentials for access to a private registry.
Sourcepub fn image_pull_credentials_type(&self) -> Option<&ImagePullCredentialsType>
pub fn image_pull_credentials_type(&self) -> Option<&ImagePullCredentialsType>
The type of credentials CodeBuild uses to pull images in your build. There are two valid values:
-
CODEBUILD
specifies that CodeBuild uses its own credentials. This requires that you modify your ECR repository policy to trust CodeBuild service principal. -
SERVICE_ROLE
specifies that CodeBuild uses your build project's service role.
When you use a cross-account or private registry image, you must use SERVICE_ROLE credentials. When you use an CodeBuild curated image, you must use CODEBUILD credentials.
Sourcepub fn docker_server(&self) -> Option<&DockerServer>
pub fn docker_server(&self) -> Option<&DockerServer>
A DockerServer object to use for this build project.
Source§impl ProjectEnvironment
impl ProjectEnvironment
Sourcepub fn builder() -> ProjectEnvironmentBuilder
pub fn builder() -> ProjectEnvironmentBuilder
Creates a new builder-style object to manufacture ProjectEnvironment
.
Trait Implementations§
Source§impl Clone for ProjectEnvironment
impl Clone for ProjectEnvironment
Source§fn clone(&self) -> ProjectEnvironment
fn clone(&self) -> ProjectEnvironment
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreSource§impl Debug for ProjectEnvironment
impl Debug for ProjectEnvironment
Source§impl PartialEq for ProjectEnvironment
impl PartialEq for ProjectEnvironment
impl StructuralPartialEq for ProjectEnvironment
Auto Trait Implementations§
impl Freeze for ProjectEnvironment
impl RefUnwindSafe for ProjectEnvironment
impl Send for ProjectEnvironment
impl Sync for ProjectEnvironment
impl Unpin for ProjectEnvironment
impl UnwindSafe for ProjectEnvironment
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);