Continuous integration (CI) is a software engineering practice that helps small-scale or large teams to collaborate better and improve their codebase. With Github Actions, you can easily integrate this into your dapptools project without using an external platform.

In this tutorial, we see how you can use Github Actions to set up a CI pipeline to your dapptools project. Before we delve into Github Actions for CI, let’s understand what continuous integration is.

Continuous integration (CI) is the software engineering practice that requires frequent commits to a shared repository. You may have gotten so used to this practice that you may wonder why there’s a term for it.

To understand this better, let us consider the opposite of CI. Before CI, people would work on feature branches for weeks or months and then try to merge this branch to a main branch. Think about all that could go wrong during such merge — merge conflicts and failing tests, just to mention a few.

Continuous integration tries to prevent all of these by encouraging small and frequent code updates. When a code is committed to a repository, it can be built and tested against setup workflows to ensure that the code does not introduce any errors.

Here are more advantages in addition to those already mentioned above:

• Fault isolation is simpler and faster. Since changes are smaller, it is easier to isolate the changes that cause a bug or regression changes in the test.

• Since CI encourages small, frequent changes, code review time is shorter

• A major part of the CI pipeline is the automated testing of critical flows for a project.

• Better code quality is ensured because you can configure the pipeline to test against linting rules.

Now, let’s consider how we can use Github Actions to configure a CI pipeline for a dapptools project.

Create new workflow file in your Github repository:

touch .github/workflows/dapptools.yaml

First, we define the name of the workflow and when to run the workflow:

name: dapptools
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

Next step, let’s define the workflow jobs:

name: dapptools
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: risedle/setup-dapptools@v4
      - run: dapp update
      - run: dapp build

That’s it. Now every pull request that target branch main and every push on main will trigger the workflow. It run the dapp build automatically to make sure that there is no error in the codebase. You can change dapp build to dapp test if you have unit test in place.

If you are using custom solidity version, please refer to risedle/setup-dapptools@v4 on how to set it up.

Solhint is a nice tool to improve your solidity codebase quality. Here is a way to run linter on every pull request:

name: dapptools
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: risedle/setup-dapptools@v4
      - run: dapp update
      - run: dapp build
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: "17.3.0"
      - run: npm i -g solhint
      - run: solhint "src/**/*.sol"

It’s very simple right? With this simple changes your Solidity codebase quality will improve++

We are core contributors of the Risedle Leveraged Token protocol.

Website | Documentation | Twitter | Discord

Continuous integration (CI) is a software engineering practice that helps small-scale or large teams to collaborate better and improve their codebase. With Github Actions, you can easily integrate this into your dapptools project without using an external platform.

In this tutorial, we see how you can use Github Actions to set up a CI pipeline to your dapptools project. Before we delve into Github Actions for CI, let’s understand what continuous integration is.

Continuous integration (CI) is the software engineering practice that requires frequent commits to a shared repository. You may have gotten so used to this practice that you may wonder why there’s a term for it.

To understand this better, let us consider the opposite of CI. Before CI, people would work on feature branches for weeks or months and then try to merge this branch to a main branch. Think about all that could go wrong during such merge — merge conflicts and failing tests, just to mention a few.

Continuous integration tries to prevent all of these by encouraging small and frequent code updates. When a code is committed to a repository, it can be built and tested against setup workflows to ensure that the code does not introduce any errors.

Here are more advantages in addition to those already mentioned above:

• Fault isolation is simpler and faster. Since changes are smaller, it is easier to isolate the changes that cause a bug or regression changes in the test.

• Since CI encourages small, frequent changes, code review time is shorter

• A major part of the CI pipeline is the automated testing of critical flows for a project.

• Better code quality is ensured because you can configure the pipeline to test against linting rules.

Now, let’s consider how we can use Github Actions to configure a CI pipeline for a dapptools project.

Create new workflow file in your Github repository:

touch .github/workflows/dapptools.yaml

First, we define the name of the workflow and when to run the workflow:

name: dapptools
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

Next step, let’s define the workflow jobs:

name: dapptools
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: risedle/setup-dapptools@v4
      - run: dapp update
      - run: dapp build

That’s it. Now every pull request that target branch main and every push on main will trigger the workflow. It run the dapp build automatically to make sure that there is no error in the codebase. You can change dapp build to dapp test if you have unit test in place.

If you are using custom solidity version, please refer to risedle/setup-dapptools@v4 on how to set it up.

Solhint is a nice tool to improve your solidity codebase quality. Here is a way to run linter on every pull request:

name: dapptools
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: risedle/setup-dapptools@v4
      - run: dapp update
      - run: dapp build
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: "17.3.0"
      - run: npm i -g solhint
      - run: solhint "src/**/*.sol"

It’s very simple right? With this simple changes your Solidity codebase quality will improve++

We are core contributors of the Risedle Leveraged Token protocol.

Website | Documentation | Twitter | Discord