In our last blog we have completed the first 3 sections of buildspec.yml file.

We will continue it from here.

3.a) Shell

• It is an optional filed.
• It specifies the supported  shell for Linux or Windows operating systems.
• For Linux, supported shell tags are
  1. Bash
  2. /bin/bash
• For Windows, supported shell tags are
  1. Powershell.exe
  2. Cmd.exe

3.b) Variables

• If env is specified then variables is mandatorily required filed.
• It is specified as key-pair values
• Each mapping represents a single custom environment variable in plain text.

3.c) Parameter-store.

• If env is specified then parameter-store is a required field.
• It is used to retrieve the custom environment variables stored in Amazon EC2 Systems Manager Parameter Store.

3.d) Secrets-Manager

• If env is specified then this field is mandatory
• It is used to retrieve the custom environment variable stored in AWS Secrets Manager in the following pattern :
  : :::

3.e) Exported-variable

• It is an optional filed
• It is used to list the environment variables you want to export.
• The variable that needs to exported shall be available in the container during the build.

3.f) Git-credential-helper

• It is an optional field
• This filed is used to provide Git Credentials. If used, specify ‘yes’ if not then ‘no’.

1. Proxy.

• It is an optional filed.
• It is used to represent the settings if you run the build in an explicit proxy server. 
• If we want your build in explicit proxy serve to upload artifacts then use proxy/upload-artifacts.
• If you want your build in an explicit proxy server to create logs then use proxy/logs.

2. Phases.

• It is a required field. 
• It specifies the commands you want to run during each phase.
• Following are the phases :
  1. Install
  2. Pre_build
  3. Build
  4. Post_build
  5. Artifacts.
• Each phase has following sections.
  1. Run-as
  2. On-failure
  3. Runtime-versions
  4. Commands
  5. Finally
• Run-as : It specifies the Linus User name that the build commands should run during the respective phase.
• On-Failure : It can have only 2 values – Abort / Continue. It defines the behaviour for the respective phase. It can be set to either abort the entire build or continue to next phase.
• Runtime-versions: It specifies the runtime versions for different programming languages or tools.
• Commands : It contains the commands that needs to be executed in the respective phase. 
• Finally : It specifies commands that run regardless of success or failure of the preceding commands in the respective phase.

4. Artifacts. 

• It is an optional sequence.
• It specifies where the output of the build shall be saved.
• We can save it at locations like S3 Bucket, Docker Hub, ECR, etc.
• If artifacts section is used then following fields shall be specified.
  • Artifacts/files :
    • It is a required field.
    • It represents the location that contain the build output artifacts in the build environment.
    • It can include the following :
      • A single file
      • A single file in sub-directory
      • ‘**/*’ : for all files recursively
      • Sub-directory/* : for all file sin sub-directory
      • Sub-directory/**/* : for all files in sub-directory recursively.
  • Artifacts/name:
    • It is an optional filed.
    • It specifies the name of the build artifact.
  • Artifact/discard-paths:
    • It is an optional field.
    • If not specified then it is considered as ‘NO’
    • If specified ‘YES’, then the build artifact will be flattened in the output.
    • Eg : if a path to a file in the build output artifact is com/mycompany/app/HelloWorld.java, specifying yes will place this file in /HelloWorld.java.
  • Artifacts/base-directory:
    • It is an optional field.
    • It tells the building tool where to start looking for files to include in the final result (artifact). 
    • Its like giving directions to find specific things in a messy room, starting from a certain corner.
  • Artifacts/exclude-paths:
    • It specifies the directories or files that should be left out from the artifact.
    • It is an optional field.
  • Artifacts/enable-symlinks:
    • It is an optional field.
    • It specifies whether symbolic links should be included in the artifact or not.
    • It can take the values ‘true’ or ‘false’
  • Artifacts/S3-prefix:
    • It is an optional filed.
    • It is used when the S3 bucket is used to save the artifacts.
  • Artifacts/secondary-artifacts:
    • It is an optional filed.
    • It is used to specify the additional set of artifacts (other than primary artifact).

5. Cache:

• It is used to configure the caching options during the build process. 
• It involves storing certain dependencies or intermediate build artifacts to speed up the subsequent builds by avoiding redundant work.
  • Cache/paths:
    • It is used to specify the directories or files that should be cached during the process.
    • If used cache section, this field becomes mandatory.

The post Demystifying the BuildSpec: Navigating the Anatomy of Your CI/CD Pipeline – PART 2 appeared first on Addend Analytics.