On the 9th of June I attended the Developer Day to be inspired by the latest innovations by SAP. I joined the Business Technology Platform Track and enjoyed the following 3 amazing sessions:

• A harmonized UX with the BTP Launchpad Service – Stijn Puttemans , Yor Rombaut  & Wouter Lemaire
• Build Resilient Apps on SAP BTP – Maximilian Streifeneder
• Accessing SAP BTP resources with API’s and CLI – DJ Adams

Sometimes people wonder or ask, what are your takeaways of this session or event? Well, mine was a bucket list, cool stuff to try out myself!

I discovered new BTP services and received a know-how on how to start with these services.

The nice thing about these kind of sessions, is that often you go home with some interesting GIT-repositories or links to SAP Developers Tutorials or such.

DJ, Max, Stijn, Wouter and Yor added the following items to my bucket list:

• Stijn, Wouter & Yor
  • Configure and Run a Predefined SAP Continuous Integration and Delivery (CI/CD) Pipeline: Configure and Run a Predefined SAP Continuous Integration and Delivery (CI/CD) Pipeline | Tutorials for SAP Developers (SAP Developers Tutorial)

I chose to start with the SAP Continuous Integration and Delivery service, since it would help me with a current project I’ve been working on.

I was quite thrilled to get started with the service, since I had the Configure and Run a Predefined SAP Continuous Integration and Delivery (CI/CD) Pipeline SAP Developers tutorial at my side.

The tutorial guided me through all the required steps and my first CI/CD flow with the SAP Continuous Integration and Delivery service was born.

SAP CI & CD – Job – Lint Check

I want to share with you the most basic ESLint example to get you started with this Lint Check option inside the SAP Continuous Integration and Delivery service its Job editor. We will create a Fiori Application, configure the CI/CD Job and ESLint configuration file.

Fiori Application – Configuration

In this example I used an SAP UI5 Freestyle Fiori Application, generated inside the SAP Business Application Studio (Fiori Workspace) with the Fiori Application generator:

I configured my project attributes as such:

Do note that for demo purposes I did not add the ESLint configuration. We will manually add this afterwards.

I chose the Cloud Foundry environment as my target and added a Managed Application Router.

You can also generate your application with the Easy UI5 Generator, this will already contain a lot of tests and scripts such as Karma and ESLint. This eases the steps to be taken, but I would like to show the minimal setup for a Lint scenario in the SAP BTP CI/CD service.

CI & CD – Configuration

In the SAP BTP CI/CD service I used the following configuration (.pipeline/config.yml) inside my Job together with the pipeline ‘SAP Fiori in the Cloud Foundry environment’:

---
general:
  buildTool: "mta"
service:
  buildToolVersion: "MBTJ11N14"
stages:
  Build:
    npmExecuteLint: true
  Additional Unit Tests:
    npmExecuteScripts: false
    karmaExecuteTests: false
  Malware Scan:
    malwareExecuteScan: false
  Acceptance:
    cloudFoundryDeploy: false
    uiVeri5ExecuteTests: false
  Compliance:
    sonarExecuteScan: false
  Release:
    cloudFoundryDeploy: true
    cfApiEndpoint: "YOUR-CF-API-ENDPOINT"
    cfOrg: "YOUR-CF-ORG"
    cfSpace: " YOUR-CF-SPACE"
    cfCredentialsId: "YOUR-BTP-CRED-NAME-IN-CI/CD"
    tmsUpload: false
steps:
  artifactPrepareVersion:
    versioningType: "cloud_noTag"
  npmExecuteLint:
    failOnError: true
  cloudFoundryDeploy:
    mtaDeployParameters: "-f --version-rule ALL"

The properties in this configuration file obviously map to the UI of the CI/CD Job configuration screen. The configuration above can be retrieved by pressing the “YML” button in the “Stages” section of your CI/CD job.

ESLint – configuration

To install the ESLint npm package as a dev-dependency, execute the following command:

npm install eslint --save-dev

To create your .eslintrc file, which contains your ESLint configuration, execute the following command:

npm init @eslint/config

When running the command above, chose the following configuration options:

You will see that your .eslintrc.json file has been created with the following content:

{
    "env": {
        "browser": true,
        "es2021": true
    },
    "parserOptions": {
        "ecmaVersion": "latest"
    },
    "rules": {
       
    }
}

The Lint Check will not find any errors, since no rules are configured.

Now let’s add the “no-debugger” rule and throw a warning when a “debugger” statement is found in the JavaScript files. Add the “es6” and “jQuery” properties to the “env” property as well, and “sap” and “jQuery” to “globals”.

The configuration file will look as such:

{
    "env": {
      "browser": true,
      "node": true,
      "es6": true,
      "jquery": true
    },
    "parserOptions": {
        "ecmaVersion": "latest"
    },
    "globals": {
      "sap": true,
      "jQuery": true
    },
    "rules": {
      "no-debugger": 1
    }
  }

The following error-levels exist:

• “off“ or 0 – turn the rule off
• “warn“ or 1 – turn the rule on as a warning (doesn’t affect exit code)
• “error“ or 2 – turn the rule on as an error (exit code will be 1)

Run CI/CD Job

Now to test the job, add a debugger-statement inside your controller file like this for example:

Delete the “Utils” and “test” directories inside your “webapp” directory and remove the “@param” line in your controller file. We only do this for demo purposes of course. The files inside those directories contain some special configuration, which requires some extra ESLint configuration, and we want to keep it basic.

Double check in your CI/CD job that you have the “Lint Check” activated, as well as the “Fail on error” option.

Execute the following git command to add, commit and push the change to your git-repository:

git add .
git commit -m "debugger statement"
git push

As you can see the build passed successfully, as well did the deployment/release:

When you press the second block (Build) you can open the logs of the build process. Here you can see that the lint command was executed successfully:

Now change your “no-debugger” rule its value from 1 to 2 (error) and commit and push to your repository.

To see in which files warnings occurred you can scroll down and see that the controller file is mentioned. (the logs show an error ‘file not found’ since it cannot create a fingerprint for the file while searching for it. But the affected files regarding your lint check are the files mentioned here):

As we expected, the build failed because of the debugger statement:

When you press the second block (Build) you can open the logs of the build process. Here you can see that the lint command was executed with errors:

To see in which files errors occurred, you can scroll down and see that the controller file is mentioned (the logs show an error ‘file not found’ since it cannot create a fingerprint for the file while searching for it. But the affected files regarding your lint check are the files mentioned here):

If you would test it with the rule “no-debugger” equal to 0 (off), you would see that the ESLint check is still performed, but the controller file is nowhere to be found in the logs, since the rule was not executed as warning or error.

Turning off the Lint Check in the CI/CD job would obviously prevent the job from executing the ESLint command.

Now give it a try with an extra rule in your .eslintrc.json file, regarding a console statement. The rule name is “no-console”, you know how to test around.

Summary

ESLint checks being performed inside a CI/CD job is a very handy feature to guarantee or force clean code inside your project. When setting up a basic lint scenario it is not a steep mountain to climb indeed, but when you are struggling and not quite familiar with ESLint, this post might help you to take your first steps and gain some insights.

I hope this can help others building there first CI/CD Job using Lint Checks in the most basic way possible.

Feel free to share your experiences, tips, tricks, and corrections along.

Best regards,

Dries