Adding our build steps

With our CircleCI configuration, we can add many steps to the process and even add things called orbs. Orbs are essentially predefined packages and commands that can enhance our build process. In this section, we will be adding an orb that was published by Snyk: https://snyk.io/. This scans and looks for bad packages that are currently in the npm ecosystem. We will add this after we have set up our build.

To get our build running and packaged into something that we can deploy, we will add the following to our CircleCI configuration:

- run: npm install
- run: npm run build

With this, we will have our system building just as if we were running locally. Let's go ahead and try it out. Follow these steps:

  1. Add our configuration file to our git commit:
> git add .circleci/config.yml
  1. Commit this to our local repository:
> git commit -m "changed configuration"
  1. Push this to our GitHub repository:
> git push

As soon as we do that, CircleCI will start up a build. If we go to the project directory in CircleCI, we will see it building. If we click on the job, we will see it running all of our steps – we will even see it running through the steps we laid out in our file. Here, we will see our build failed!

This has happened because when we installed Rollup, we installed it as a global item. In this case, we need to add it as a dev dependency in our package.json file. If we add it to our package.json file, we should have a devDependency section that looks like this:

"devDependencies": {
"rollup-plugin-sass": "^1.2.2",
"rollup-plugin-terser": "^5.1.2",
"rollup-plugin-uglify": "^6.0.3",
"rollup": "^1.27.5"
}

Now, if we commit and push these files to our GitHub repository, we will see that our build passes!

With a passing build, we should add the Snyk orb to our configuration. If we head to https://circleci.com/orbs/registry/orb/snyk/snyk, we will see all of the commands and the configuration that we need to set up. Let's go ahead and change our config.yml file in order to bring the Snyk orb in. We will check our repository after we have built it. This should look like this:

version: 2.1
orbs:
snyk: snyk/[email protected]
jobs: build:
docker:
- image: circleci/node:12.13
working_directory: ~/repo
steps:
- checkout
- run: npm install
- snyk/scan
- run: npm run build

With the preceding configuration, we can go ahead and commit/push to our GitHub repository and see the new run of our build. It should fail because it will not allow us to run third-party orbs unless we explicitly state that we want to run them. We can do this by heading to our settings and going to the Security section. Once there, go ahead and state that we want to use third-party orbs. With this checked, we can do another build and we will see that we fail again!

We will need to sign up with Snyk to use their orb. Go ahead and head to snyk.io and sign up with a GitHub account. Then, go to the Account settings section. From there, grab the API token and head to the Settings and contexts section.

Create a new context and add the following environment variable:

SNYK_TOKEN : <Your_API_Key>

To utilize contexts, we will need to change up our config.yml file a bit. We will need to add in a workflows section and tell it to run our build job with that context. The file should look something like the following:

version : 2.1
orbs:
snyk: snyk/[email protected]
jobs:
build:
docker:
- image: circleci/node:12.13
working_directory: ~/repo
steps:
- checkout
- restore_cache:
keys:
- v1-dependencies-{{ checksum "package.json" }}
- v1-dependencies-
- run: npm install
- snyk/scan
- run: npm run build
- save_cache:
paths:
- node_modules
key: v1-dependencies-{{ checksum "package.json" }}
workflows:
version: 2
build_and_deploy:
jobs:
- build:
context: build

With that change, we can go ahead and push it to the remote repository. We will see that the build passes with Snyk security scanning our packages!

The idea of contexts is to hide API keys and secrets from the configuration file. We don't want to put those in our configuration files since anyone would be able to see them. Instead, we put them in something such as a context, where the administrators of a project will be able to see them. Every CI/CD system should have a concept like this, and this should be used whenever there are items like this.

With our project building and being scanned, all we need to do is deploy our application to a machine!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.136.233.153