Tutorial : Build and test Node.js applications

 Cloud Build enables you to use any publicly available container image to execute your tasks. The public node image from Docker Hub comes preinstalled with the npm tool. You can configure Cloud Build to build your Node.js project with this tool.

The instructions on this page assume that you are familiar with Node.js. In addition:

To execute your tasks in the node image from Docker Hub, specify the image URL in the name field in the Cloud Build config file. Cloud Build starts the container specified in the name field using the image's default entrypoint. To override the default entrypoint and define how the build step should be run when it is invoked, add an entrypoint field in your build step. The node image in Docker Hub comes preinstalled with the npm tool. Specify the tools in the entrypoint field to invoke them as the entrypoint of your build step.

In the following example build config file:

  • The name field specifies that the node image from Docker Hub is used by Cloud Build to execute your task. When you're specifying the node image, you can either omit the node version to default to :latest, or specify a node version to use a specific version. For example, name: node will use the latest version of node, and name: node:12 will use node:12.

  • The entrypoint field specifies that the npm tool is used when the node image is invoked.

     steps:
         - name: 'node'
       entrypoint    : 'npm'

  1. In your project root directory, create a config file named cloudbuild.yaml.

  2. Install dependencies: Before you can build your application, you must ensure that all of your project's dependencies are installed from npm. You can install dependencies using the install command within the npm build step. The args field of a build step takes a list of arguments and passes them to the image referenced by the name field. In your build config file, add install to the args field to invoke the install command:

     steps:
         - name: 'node'
       entrypoint    : 'npm'
       args    : ['install']

  3. Add tests: If you've defined a test script in your package.json, you can configure Cloud Build to run the script by adding test to the args field:

     steps:
         - name: 'node'
       entrypoint    : 'npm'
       args    : ['install']
         - name: 'node'
       entrypoint    : 'npm'
       args    : ['test']

  4. Run custom commands: If your package.json contains any custom commands, you can configure Cloud Build to run that command. In the args field, add run as the first argument followed by the name of the custom command. The following build config file has arguments to run a custom command called build:

     steps:
         - name: 'node'
        entrypoint    : 'npm'
        args    : ['install']
         - name: 'node'
        entrypoint    : 'npm'
        args    : ['test']
         - name: 'node'
        entrypoint    : 'npm'
        args    : ['run', 'build']

  5. Upload to Artifact Registry:

    Cloud Build generates Supply chain Levels for Software Artifacts (SLSA) build provenance information for standalone npm packages when you upload them to Artifact Registry using the npmPackages field in your Cloud Build config file.

    In your config file, add the npmPackages field and specify your npm repository in Artifact Registry:

     artifacts:
        npmPackages    :
            - repository: 'https://LOCATION-npm.pkg.dev/PROJECT-ID/REPOSITORY_NAME'
          packagePath    : 'PACKAGE_PATH'

    Replace the following values:

    • LOCATION: the location for your repository in Artifact Registry.
    • PROJECT_ID: the ID of the Google Cloud project that contains your Artifact Registry repository.
    • REPOSITORY_NAME: the name of your npm repository in Artifact Registry.
    • PACKAGE_PATH: the path for the local directory containing the npm package that you want to upload to Artifact Registry. We recommend using an absolute path. Your PACKAGE_PATH value can be . to use the current working directory, but the field cannot be omitted or left empty. This directory must contain a package.json file.

  6. Optional: Enable provenance for regional builds

    If you are using a regional build, add the requestedVerifyOption field in the options in your build config file. Set the value to VERIFIED to enable provenance metadata generation. If you don't add requestedVerifyOption: VERIFIED, Cloud Build generates provenance for global builds only.

    options:
      requestedVerifyOption    : VERIFIED

  7. Start your build: manually or using build triggers.

    Once your build completes, you can view repository details in Artifact Registry.

    You can also view build provenance metadata and validate provenance to help protect your software supply chain.

Sometimes it is necessary to ensure that your project works across multiple versions of node. You can create and configure Cloud Build triggers such that:

  • In your build config file, specify the node version as a substitution variable.
  • Create one trigger for each version of node against which you want to build your application.
  • In each of the trigger settings, use the substitution variable value field to indicate the version of the node for that trigger.

The following steps explain how to specify the node version using trigger-specific substitution variables:

  1. In your repository root, add a build config file, which specifies the nodeversion as a substitution variable. In the following example build config file, $_NODE_VERSION is a user-defined substitution variable:

     steps:
         - name: 'node:$_NODE_VERSION'
       entrypoint    : 'npm'
       args    : ['install']
         - name: 'node:$_NODE_VERSION'
       entrypoint    : 'npm'
       args    : ['test']

  2. For each version of node you want to build against, create a build trigger using the following steps:

    1. Open the Triggers page in the Google Cloud console:

      Open Triggers page

    2. Select your project from the project selector drop-down menu at the top of the page.

    3. Click Open.

    4. Click Create trigger.

      On the Create trigger page, enter the following settings:

      1. Enter a name for your trigger.

      2. Select the repository event to start your trigger.

      3. Select the repository that contains your source code and build config file.

      4. Specify the regex for the branch or tag name that will start your trigger.

      5. Configuration: Choose the build config file you created previously.

      6. Under Substitution variables, click Add variable.

        1. Under Variable, specify the node version variable you used in your build config file, and under Value specify the version of the node. For example, _NODE_VERSION and 12.

    5. Click Create to save your build trigger.

You can use these triggers to build your code on the version of node you specified in the trigger.

Comments

Post a Comment

Popular posts from this blog

Terraform

Image
  Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. How does Terraform work? Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. HashiCorp and the Terraform community have already written  thousands of providers  to manage many different types of resources...
Read more

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario,  MoSCoW prioritization  becomes essential to ensure the successful completion of the project.  Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes. What is the MoSCoW prioritization technique?  The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for  Must have ,  Should have ,  Could have , and  Won’t have , each denoting a level of priority. Here is the breakdown of the MoSCoW method:  Must have:  These are critical requirements that the project cannot be completed withou...
Read more