Class ProjectCache
- All Implemented Interfaces:
Serializable
,SdkPojo
,ToCopyableBuilder<ProjectCache.Builder,
ProjectCache>
Information about the cache for the build project.
- See Also:
-
Nested Class Summary
-
Method Summary
Modifier and TypeMethodDescriptionstatic ProjectCache.Builder
builder()
final boolean
final boolean
equalsBySdkFields
(Object obj) Indicates whether some other object is "equal to" this one by SDK fields.final <T> Optional
<T> getValueForField
(String fieldName, Class<T> clazz) final int
hashCode()
final boolean
hasModes()
For responses, this returns true if the service returned a value for the Modes property.final String
location()
Information about the cache location:modes()
An array of strings that specify the local cache modes.An array of strings that specify the local cache modes.static Class
<? extends ProjectCache.Builder> Take this object and create a builder that contains all of the current property values of this object.final String
toString()
Returns a string representation of this object.final CacheType
type()
The type of cache used by the build project.final String
The type of cache used by the build project.Methods inherited from interface software.amazon.awssdk.utils.builder.ToCopyableBuilder
copy
-
Method Details
-
type
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.
If the service returns an enum value that is not available in the current SDK version,
type
will returnCacheType.UNKNOWN_TO_SDK_VERSION
. The raw value returned by the service is available fromtypeAsString()
.- Returns:
- 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.
-
- See Also:
-
-
typeAsString
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.
If the service returns an enum value that is not available in the current SDK version,
type
will returnCacheType.UNKNOWN_TO_SDK_VERSION
. The raw value returned by the service is available fromtypeAsString()
.- Returns:
- 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.
-
- See Also:
-
-
location
Information about the cache location:
-
NO_CACHE
orLOCAL
: This value is ignored. -
S3
: This is the S3 bucket name/prefix.
- Returns:
- Information about the cache location:
-
NO_CACHE
orLOCAL
: This value is ignored. -
S3
: This is the S3 bucket name/prefix.
-
-
-
modes
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.
-
Attempts to modify the collection returned by this method will result in an UnsupportedOperationException.
This method will never return null. If you would like to know whether the service returned this field (so that you can differentiate between null and empty), you can use the
hasModes()
method.- Returns:
- 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.
-
-
hasModes
public final boolean hasModes()For responses, this returns true if the service returned a value for the Modes property. This DOES NOT check that the value is non-empty (for which, you should check theisEmpty()
method on the property). This is useful because the SDK will never return a null collection or map, but you may need to differentiate between the service returning nothing (or null) and the service returning an empty collection or map. For requests, this returns true if a value for the property was specified in the request builder, and false if a value was not specified. -
modesAsStrings
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.
-
Attempts to modify the collection returned by this method will result in an UnsupportedOperationException.
This method will never return null. If you would like to know whether the service returned this field (so that you can differentiate between null and empty), you can use the
hasModes()
method.- Returns:
- 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.
-
-
toBuilder
Description copied from interface:ToCopyableBuilder
Take this object and create a builder that contains all of the current property values of this object.- Specified by:
toBuilder
in interfaceToCopyableBuilder<ProjectCache.Builder,
ProjectCache> - Returns:
- a builder for type T
-
builder
-
serializableBuilderClass
-
hashCode
public final int hashCode() -
equals
-
equalsBySdkFields
Description copied from interface:SdkPojo
Indicates whether some other object is "equal to" this one by SDK fields. An SDK field is a modeled, non-inherited field in anSdkPojo
class, and is generated based on a service model.If an
SdkPojo
class does not have any inherited fields,equalsBySdkFields
andequals
are essentially the same.- Specified by:
equalsBySdkFields
in interfaceSdkPojo
- Parameters:
obj
- the object to be compared with- Returns:
- true if the other object equals to this object by sdk fields, false otherwise.
-
toString
Returns a string representation of this object. This is useful for testing and debugging. Sensitive data will be redacted from this string using a placeholder value. -
getValueForField
-
sdkFields
-