Leverage JHipster to build your CI pipelines quickly

Hi, my fellow developers,

After having discovered the top 3 features I like to use with GitHub Actions, I’d like to share how you can easily create your own pipelines for a JHipster generated project using the ci-cd generator, with multiple choices of pipeline solutions.

Let’s discover this awesome feature to build your pipelines quickly!

Before diving into the details about building a pipeline, I’d like to remind you how JHipster is built. When you run the CLI using the jhipster command, a few parts of the generators that compose JHipster will be launched one after the other, following the core engine definitions of this sequence.

However, some of the sub-generators included in the JHipster npm package can be called manually to complete a specific task, such as creating a pipeline file definition for an existing application.

Requirements

To generate a pipeline you need to have an existing JHipster application or create a new one.

• Install the last JHipster version: npm i generator-jhipster
• Run the default JHipster command: jhipster
• Select the options you want or use the defaults

Once the project is generated and the npm install command has been run, you can go ahead and create a pipeline.

Generate a pipeline file

In your project folder, run the following command: jhipster ci-cd.

The first step is to select what kind of pipeline you want to generate.

JHipster currently supports Jenkins, GitLab CI, GitHub Actions, Travis CI, and Circle CI.

According to the type of platform chosen, you will need to answer some questions that could be specific to it or ask for each of these provided solutions.

Here is an example of questions you have to ask if you choose GitHub Actions:

Each task adds a new step in the pipeline or adapts the configuration to match the user requirements. As per usual with JHipster, the flexibility of the generator offers a few different capabilities in the final generated product.

It could be, for example, adding a security step with Snyk dependency scanning or analyzing the code with Sonar.

By choosing Sonar here, I answered two more questions to configure it and make it work out of the box.

Finally, the pipeline definition file is generated at this path.github/workflows/github-actions.yml

The GitHub Actions Workflow file in detail

The Github Actions generated file contains a lot of defined actions to have an out-of-the-box viable CI:

name: Application CI
on: [push, pull_request]
jobs:
   pipeline:
       name: cicd pipeline
       runs-on: ubuntu-latest
       if: "!contains(github.event.head_commit.message, '[ci skip]') && !contains(github.event.head_commit.message, '[skip ci]') && !contains(github.event.pull_request.title, '[skip ci]') && !contains(github.event.pull_request.title, '[ci skip]')"
       timeout-minutes: 40
       env:
           NODE_VERSION: 14.17.6
           SPRING_OUTPUT_ANSI_ENABLED: DETECT
           SPRING_JPA_SHOW_SQL: false
           JHI_DISABLE_WEBPACK_LOGS: true
           NG_CLI_ANALYTICS: false
       steps:
           - uses: actions/checkout@v2
           - uses: actions/setup-node@v1
             with:
                 node-version: 14.17.6
           - uses: actions/setup-java@v2
             with:
                 distribution: 'temurin'
                 java-version: 11
           - name: Install node.js packages
             run: npm install
           - name: Run backend test
             run: |
                 chmod +x mvnw
                 npm run ci:backend:test
           - name: Run frontend test
             run: npm run ci:frontend:test
           - name: Analyze code with SonarQube
             env:
                 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
                 SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
             run: |
                 if [ ! -z "$SONAR_TOKEN" ]; then
                     ./mvnw -ntp initialize sonar:sonar -Dsonar.host.url=https://sonarcloud.io
                 else
                     echo No SONAR_TOKEN, skipping...
                 fi
           - name: Package application
             run: npm run java:jar:prod

By using this solution you will be able to leverage the community knowledge on CI definition and use the proper version for each tool needed such as Java and NodeJS versions. If you upgrade your JHipster version, you can generate the pipeline file again to upgrade it or upgrade yours.

This workflow executes the following steps:

• Checkout the project
• Install NodeJS
• Install Java
• Run the npm install command
• Run both backend and frontend tests
• Run the Sonar analysis we added during the previous step
• Package the application

Update the pipeline to automatically deploy your application to Heroku

In order to turn your pipeline into a continuous deployment one, JHipster provides a simple solution using Heroku as a provider.

You simply need to select the following task “Deploy to Heroku” when you generate the pipeline.

Then a new task is added in the pipeline named Deploy to Heroku, launched only when new commits are added on the main branch. To be sure this works, you need to add a new secret in your GitHub repository HEROKU_API_KEYand have a Heroku account.

Conclusion

I hope this article helps you to understand this feature from JHipster and you are willing to use it in your applications to create great pipelines to automatically test them and reach your KPIs.

Of course, a lot of details remain to be discovered, such as the different platforms to run your pipelines or all the options provided by JHipster.

It could be another story I’d like to share with you… Stay tuned!