{"id":4495,"date":"2022-11-19T00:47:00","date_gmt":"2022-11-19T06:47:00","guid":{"rendered":"https:\/\/www.supportpro.com\/blog\/?p=4495"},"modified":"2022-11-21T11:18:02","modified_gmt":"2022-11-21T17:18:02","slug":"local-caching-in-aws-codebuild","status":"publish","type":"post","link":"https:\/\/www.supportpro.com\/blog\/local-caching-in-aws-codebuild\/","title":{"rendered":"Local Caching in AWS CodeBuild"},"content":{"rendered":"\n

AWS CodeBuild <\/strong>is a completely overseen persistent incorporation administration. You simply indicate the area of your source code, pick your construct settings, and CodeBuild will run manufacture contents for accumulating, testing, and bundling your code. There are no servers for provisioning and scaling purposes, or software for installation, configuration, and operation.<\/span><\/p>\n\n\n\n

Build Caching <\/b>in<\/b> CodeBuild<\/b><\/h2>\n\n\n\n

A cache can store reusable bits of your build environment and use them over various build. By using a cache, you can save more time in the project build setup.<\/span><\/p>\n\n\n\n

AWS CodeBuild now enables you to store antiques locally on the build with little cost as well as quicker reuse. You could just utilize Amazon S3 as the cache to store your ancient rarities between builds. Despite the fact that S3 caching permits the reuse of relics, it accompanies a network cost and inactivity because of the related file transfer.<\/span><\/p>\n\n\n\n

Now AWS CodeBuild supports Local caching, which makes it feasible for you to continue intermediate build artifacts locally on the build host so that they are accessible for reuse resulting in build runs.<\/span><\/p>\n\n\n\n

Two types of caching<\/b><\/h2>\n\n\n\n

1) Amazon S3 Caching<\/b><\/h3>\n\n\n\n

It stores the cache in an Amazon S3 <\/a>bucket that is accessible over different build hosts. This is a decent choice for small intermediate build vestige that is more costly to build than to download. This isn’t the best alternative for enormous build artifacts since they can set aside a long time to transfer over your network, which is depended on the build performance.<\/span><\/p>\n\n\n\n

2) Local Caching<\/b> <\/span><\/h3>\n\n\n\n

Local caching stores a cache locally on a host that is accessible to the build host only. This is a perfect and alternative option for build artifacts since the cache is immediately available on the build host. This implies that build performance is not impacted by network transfer time. Also, do note that if you choose to build, performance is not impacted by network transfer time. While choosing local caching, you have to choose one or more of the following cache modes.<\/span><\/p>\n\n\n\n

Local caching increases build performance for:<\/span><\/p>\n\n\n\n

    Projects with a large, monolithic source code repository.<\/span><\/p>\n\n\n\n

    Projects that create and reuse many intermediate build artifacts.<\/span><\/p>\n\n\n\n

    Projects that build large Docker images.<\/span><\/p>\n\n\n\n

    Projects with many source dependencies.<\/span><\/p>\n\n\n\n

How to use Codebuild local caching<\/b><\/h2>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
  1. Open AWS CodeBuild console at https:\/\/console.aws.amazon.com\/codesuite\/codebuild\/home.<\/span><\/li>
  2. Select Create project.<\/span><\/li>
  3. In Project configuration, enter a name and description for the build project.<\/span><\/li>
  4. In Source, for Source provider, select the source code provider type. We use an AWS CodeCommit repository name in this example.<\/span><\/li>
  5. For Environment image, choose the Managed image or Custom image, as appropriate. For environment type, choose Linux or Windows Server. Specify a runtime, runtime version, and service role in relation to your project.<\/span><\/li>
  6. Configure the build spec file for your project.<\/span><\/li>
  7. In Artifacts, expand Additional Configuration. For Cache type, choose Local, as shown here.<\/span><\/li><\/ol>\n\n\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n\n

    Local caching supports the below mentioned caching modes:<\/span><\/p>\n\n\n\n

    a) Source cache mode<\/b> caches Git metadata for primary and secondary sources. After the cache has been created, subsequent builds pull just the change between commits. This mode is a decent decision for projects with a perfect working directory and a source that is a huge Git repository. If you are choosing this option and your project does not use a Git repository (GitHub, GitHub Enterprise, or Bitbucket), the option is ignored. <\/span><\/p>\n\n\n\n

    b) Docker layer cache mode<\/b> caches subsist Docker layers. This mode is a perfect selection for projects that build or pull large Docker images. It can avoid the performance matter caused by pulling large Docker images down from the network. <\/span><\/p>\n\n\n\n

    Note:<\/span><\/p>\n\n\n\n