#[non_exhaustive]pub struct ProjectCache {
pub type: CacheType,
pub location: Option<String>,
pub modes: Option<Vec<CacheMode>>,
pub cache_namespace: Option<String>,
}
Expand description
Information about the cache for 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: CacheType
The type of cache used by the build project. Valid values include:
-
NO_CACHE
: The build project does not use any cache. -
S3
: The build project reads and writes from and to S3. -
LOCAL
: The build project stores a cache locally on a build host that is only available to that build host.
location: Option<String>
Information about the cache location:
-
NO_CACHE
orLOCAL
: This value is ignored. -
S3
: This is the S3 bucket name/prefix.
modes: Option<Vec<CacheMode>>
An array of strings that specify the local cache modes. You can use one or more local cache modes at the same time. This is only used for LOCAL
cache types.
Possible values are:
- LOCAL_SOURCE_CACHE
-
Caches Git metadata for primary and secondary sources. After the cache is created, subsequent builds pull only the change between commits. This mode is a good choice for projects with a clean working directory and a source that is a large Git repository. If you choose this option and your project does not use a Git repository (GitHub, GitHub Enterprise, or Bitbucket), the option is ignored.
- LOCAL_DOCKER_LAYER_CACHE
-
Caches existing Docker layers. This mode is a good choice for projects that build or pull large Docker images. It can prevent the performance issues caused by pulling large Docker images down from the network.
-
You can use a Docker layer cache in the Linux environment only.
-
The
privileged
flag must be set so that your project has the required Docker permissions. -
You should consider the security implications before you use a Docker layer cache.
-
- LOCAL_CUSTOM_CACHE
-
Caches directories you specify in the buildspec file. This mode is a good choice if your build scenario is not suited to one of the other three local cache modes. If you use a custom cache:
-
Only directories can be specified for caching. You cannot specify individual files.
-
Symlinks are used to reference cached directories.
-
Cached directories are linked to your build before it downloads its project sources. Cached items are overridden if a source item has the same name. Directories are specified using cache paths in the buildspec file.
-
cache_namespace: Option<String>
Defines the scope of the cache. You can use this namespace to share a cache across multiple projects. For more information, see Cache sharing between projects in the CodeBuild User Guide.
Implementations§
Source§impl ProjectCache
impl ProjectCache
Sourcepub fn type(&self) -> &CacheType
pub fn type(&self) -> &CacheType
The type of cache used by the build project. Valid values include:
-
NO_CACHE
: The build project does not use any cache. -
S3
: The build project reads and writes from and to S3. -
LOCAL
: The build project stores a cache locally on a build host that is only available to that build host.
Sourcepub fn location(&self) -> Option<&str>
pub fn location(&self) -> Option<&str>
Information about the cache location:
-
NO_CACHE
orLOCAL
: This value is ignored. -
S3
: This is the S3 bucket name/prefix.
Sourcepub fn modes(&self) -> &[CacheMode]
pub fn modes(&self) -> &[CacheMode]
An array of strings that specify the local cache modes. You can use one or more local cache modes at the same time. This is only used for LOCAL
cache types.
Possible values are:
- LOCAL_SOURCE_CACHE
-
Caches Git metadata for primary and secondary sources. After the cache is created, subsequent builds pull only the change between commits. This mode is a good choice for projects with a clean working directory and a source that is a large Git repository. If you choose this option and your project does not use a Git repository (GitHub, GitHub Enterprise, or Bitbucket), the option is ignored.
- LOCAL_DOCKER_LAYER_CACHE
-
Caches existing Docker layers. This mode is a good choice for projects that build or pull large Docker images. It can prevent the performance issues caused by pulling large Docker images down from the network.
-
You can use a Docker layer cache in the Linux environment only.
-
The
privileged
flag must be set so that your project has the required Docker permissions. -
You should consider the security implications before you use a Docker layer cache.
-
- LOCAL_CUSTOM_CACHE
-
Caches directories you specify in the buildspec file. This mode is a good choice if your build scenario is not suited to one of the other three local cache modes. If you use a custom cache:
-
Only directories can be specified for caching. You cannot specify individual files.
-
Symlinks are used to reference cached directories.
-
Cached directories are linked to your build before it downloads its project sources. Cached items are overridden if a source item has the same name. Directories are specified using cache paths in the buildspec file.
-
If no value was sent for this field, a default will be set. If you want to determine if no value was sent, use .modes.is_none()
.
Sourcepub fn cache_namespace(&self) -> Option<&str>
pub fn cache_namespace(&self) -> Option<&str>
Defines the scope of the cache. You can use this namespace to share a cache across multiple projects. For more information, see Cache sharing between projects in the CodeBuild User Guide.
Source§impl ProjectCache
impl ProjectCache
Sourcepub fn builder() -> ProjectCacheBuilder
pub fn builder() -> ProjectCacheBuilder
Creates a new builder-style object to manufacture ProjectCache
.
Trait Implementations§
Source§impl Clone for ProjectCache
impl Clone for ProjectCache
Source§fn clone(&self) -> ProjectCache
fn clone(&self) -> ProjectCache
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreSource§impl Debug for ProjectCache
impl Debug for ProjectCache
Source§impl PartialEq for ProjectCache
impl PartialEq for ProjectCache
impl StructuralPartialEq for ProjectCache
Auto Trait Implementations§
impl Freeze for ProjectCache
impl RefUnwindSafe for ProjectCache
impl Send for ProjectCache
impl Sync for ProjectCache
impl Unpin for ProjectCache
impl UnwindSafe for ProjectCache
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);