Forem: Sahanon Phisetpakasit

How to setup Semantic Release with GitHub Actions.

Sahanon Phisetpakasit — Fri, 29 Mar 2024 11:35:20 +0000

Recently, My coworker is using Nx to automate his workflow, including automated release using semantic version. I found this method quite useful, so I want to re-implement on single GitHub repositories (without Nx).

First Step: Create GitHub's Personal Access Token

You can follow this link on how to create Personal Access Token.
You can choose Fine-grained tokens as you can scope specific repositories. (Or Token (Classic))

Make sure that you grant repository permission to token. For my configuration I use:

Read Access

variables
environments
metadata (default)
secrets

Read/Write Access

code
commit statuses
issue
pull requests
workflows

I might grant unnecessary permission, so feel free to correct me.

Second Step: Setup GitHub token in repository's environment

1.Go to Settings options

2.Select Environments

3.Create Environment

4.Create Environment Secret

I use GH_TOKEN to represent GITHUB_TOKEN (GitHub does not allow naming variables with prefix "GITHUB").

Third Step: Setup workflows

I use this package -> Action for Semantic Release to setup my workflow.
Use this script to create workflow

name: test
on:
  push:
    branches:
      # Change this if your primary branch is not main
      - master
      - dev

jobs:
  main:
    runs-on: ubuntu-latest
    environment:
      name: Semver #your environment name
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Semantic Release
        uses: cycjimmy/semantic-release-action@v4
        env:
          GH_TOKEN: ${{ secrets.GH_TOKEN }}

In this code snippets, it's meant to

setup environment
perform semantic release

Fourth Step: Create `.releaserc`

This will be semantic-release configuration file for

create release tag
create change log
define commit message convention -> conventionalcommits

Create .releaserc in your project.

{
    "branches": [
        "master",
        "dev"
    ],
    "plugins": [
        "@semantic-release/commit-analyzer",
        "@semantic-release/release-notes-generator",
        [
            "@semantic-release/changelog",
            {
                "changelogFile": "CHANGELOG.md"
            }
        ],
        [
            "@semantic-release/git",
            {
                "assets": [
                    "CHANGELOG.md"
                ]
            }
        ],
        "@semantic-release/github"

    ]
}

Final Step: Add, Commit and Push

This step will be the byproduct of your work so far.

Once you commit your code with message convention, for example, feat: add some features, it will trigger the semantic-release. Default convention message with angular preset included:

fix -> bug fixes: patch release
feat -> feature: minor release
breaking change -> break change: major release

Once you push your code it will run GitHub Action and release your project.

Then it will create Release and CHANGELOG.md in the project.

Conclusion

semantic-release can help you automate your versioning and release. Also, It's really useful for tracking and change in document.

Feel free to comment or give feedbacks. I'm appreciate your time for reading 😄.

Reference

https://www.conventionalcommits.org/en/v1.0.0/
https://github.com/marketplace/actions/action-for-semantic-release

Or my sample repository -> https://github.com/Sahanon-P/semver-sample

Funny mistake when I was using Axios Interceptor.

Sahanon Phisetpakasit — Tue, 05 Mar 2024 14:03:51 +0000

This story just happened today when I was working with my previous project, which I intended to enhance some features, according to the feedback. Normally, I use the Axios Interceptor to intercept my request and response from the API server.
Additionally, I'd already set based urls and headers for fetching a request.

import axios from 'axios';

function getAccessToken() {
  return localStorage.getItem('access_token');
}
const axiosPublic = axios.create({
  baseURL: import.meta.env.VITE_SERVER,
  headers: {
    'Content-Type': 'application/json',
  },
});

axiosPublic.interceptors.request.use(
  async (config) => {
    if (getAccessToken()) {
      config.headers['Authorization'] = `Bearer ${getAccessToken()}`;
    }
    return config;
  },
  (error) => {
    Promise.reject(error);
  },
);

axiosPublic.interceptors.response.use(
  (response) => {
    return response;
  },
  async (error) => {
    if (error.response) {
      if (error.response.status === 401) {
        window.alert('Session Expired');
        window.localStorage.clear();
        window.location.reload();
      }
    }
  },
);

export default axiosPublic;

This code snippet was meant to:

Set based url -> so we can make url much shorter when fetching request.
Set request header -> so we can call an API with authorization.
Handle token expired -> so when the token expired the user will be forced to log out.

Due to my lack of testing and error handling, I never discovered this misbehavior before. When I'm trying to catch some errors that were thrown from the server's response, I couldn't catch it.

You guys might wonder, "Isn't it obvious? The answer was lied in your interceptor. I bet all experienced developers can fix this at first glance." Honestly, I can't argue with that 😅, but it made me have more understanding in what interceptor does.

As you guys can see, the interceptor caught an error when the server threw back with 401. What about the others? It did nothing when other errors were thrown. Therefore, it couldn't catch anything.

To fix this problem, I came up with this solution.

axiosPublic.interceptors.response.use(
  (response) => {
    return response;
  },
  async (error) => {
    if (error.response) {
      if (error.response.status === 401) {
        window.alert('Session Expired');
        window.localStorage.clear();
        window.location.reload();
      }
      else {
        throw error;
      }
    }
  },
);

Instead of sitting still and doing nothing with the other errors, just throw them. This way, when we call an API and get an error other than 401, we can catch it.

Or you might want to handle another error in an interceptor.

axiosPublic.interceptors.response.use(
  (response) => {
    return response;
  },
  async (error) => {
    if (error.response) {
      if (error.response.status === 401) {
        // I used SweetAlert to present the message
        // Very neat and nice modal.
        return Swal.fire({
          title: 'Error',
          text: 'Session Expired',
          icon: 'error',
        }).then(() => {
          window.localStorage.clear();
          window.location.reload();
        })
      }
      if (error.response.status === 400) {
        return Swal.fire({
          title: 'Error',
          text: 'Bad Request',
          icon: 'error',
        }).then(() => {
          window.location.reload();
        })
      }
      else {
        throw error;
      }
    }
  },
);

And again, hope you enjoy the story. Please feel free to leave any comment or thoughts. I really appreciate your time for reading my blog 😄.

Setup Docker for integration testing in GitHub Action.

Sahanon Phisetpakasit — Mon, 25 Jul 2022 16:03:00 +0000

Nowadays, Continuous Integration helps developers to automate their own build and test in remote repositories. Moreover, when we work as a team, CI ensures that all the branches on remote repositories will be tested by automated build. So In my very first post, I would like to tell you my experience about how I create integration testing with docker and Github action.

Overview

Suppose that we have got 4 services, let’s call it service A, B, C and D respectively. Each service will have its own database system and dependencies between each service.

To make us have the same picture and view for what we are going to do, we are going to test services A which have dependencies with service B, C and D on the github repository. This practice will be much easier when we perform in a local environment but in a remote environment it has something that we need to work on but trust me you will get used to this after you have failed 4 or 5 times.

Setup Github Actions

Let’s begin with setting up a github action. With this Github feature it allows you to build and test your code automatically. We can choose either to use default configure that generated by Github action or to set up our own workflow.

Once we have our choice we are going to create a configuration, The configuration will be yml file and will be created in .github/workflow directory. In this example we will use yarn as a package manager tools.

#Sample yaml configuration
name: "CI"
on:
  pull_request:
  push:
    branches:
      - master
      - "releases/*"

jobs:
  # Integration Test
  tests:
    name: "Integration Test"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - run: yarn
      - run: yarn test

Create Docker compose for building the service container

Assume that we already created a docker file and image for building a container, one of the main problems that I made my build failed a lot of times is the network. Normally if our docker container is standalone and doesn't have any integration with other services, it will work completely fine but in this case which involves a lot of services for testing, without a network, the services can’t communicate with each other.

# sample docker-compose.yml for service A
version: '3'
services:
  #database for service A
  service-a-db:
    image: mongo
    networks:
      - testing-network

  service-a:
    image: <your-docker-repo-name>/service-a
    restart: always
    depends_on:
      - mongo
    ports:
      - 8888:8888
    networks:
      - testing-network
    environment:
      # your environment variable

# network can be any name but make sure it use a same name.
networks:
  testing-network:

From the sample yaml configuration, service A has one database service call service-a-db which has the same network with service A. With this configuration service A will be in the same network with service A’s database. The sample below will show all the configuration of every service in the docker-compose.yml file.

#docker-compose.yml
version: '3'
services:
  #database for service A
  service-a-db:
    image: mongo
    networks:
      - testing-network

  service-a:
    image: <your-docker-repo-name>/service-a
    restart: always
    depends_on:
      - mongo
    ports:
      - 8888:8888
    networks:
      - testing-network
    environment:
      SERVICE_D_HOST=localhost
      SERVICE_D_PORT=8080
      DB_HOST = mongo
      DB_PORT = 27017

#database for service B
  service-b-db:
    image: mongo
    networks:
      - testing-network

  service-b:
    image: <your-docker-repo-name>/service-b
    restart: always
    depends_on:
      - mongo
    ports:
      - 45000:45000
    networks:
      - testing-network
    environment:
      DB_HOST = mongo
      DB_PORT = 27017

#database for service C
  service-c-db:
    image: mongo
    networks:
      - testing-network

  service-c:
    image: <your-docker-repo-name>/service-c
    restart: always
    depends_on:
      - mongo
    ports:
      - 4000:4000
    networks:
      - testing-network
    environment:
      SERVICE_B_HOST=localhost
      SERVICE_B_PORT=45000
      DB_HOST = mongo
      DB_PORT = 27017

#database for service D
  service-d-db:
    image: mongo
    networks:
      - testing-network

  service-d:
    image: <your-docker-repo-name>/service-d
    restart: always
    depends_on:
      - mongo
    ports:
      - 8080:8080
    networks:
      - testing-network
    environment:
      SERVICE_B_HOST=localhost
      SERVICE_B_PORT=45000
      SERVICE_C_HOST=localhost
      SERVICE_C_PORT=4000
      DB_HOST = mongo
      DB_PORT = 27017

networks:
  testing-network:

Unfortunately, only network setup in configuration won’t be enough for making a communication between services. In normal use cases, we will use ’localhost as a default host name for a service but localhost is mostly suitable for local environments which are not remotely capable. So we need to change the host name to be a service name so when it runs inside the docker environment, each service can recognize each other within the same network. For example, In the diagram, service A has a dependency with service D so we should change SERVICE_D_HOST from localhost to service-d which is a name of the service that service A integrates with. Also service A has a database service call service-a-db so we should change the DB_HOST to a service name. After we change all the host name and db name, the final outcome will look like this.

# docker-compose.yml
version: '3'
services:
  #database for service A
  service-a-db:
    image: mongo
    networks:
      - testing-network

  service-a:
    image: <your-docker-repo-name>/service-a
    restart: always
    depends_on:
      - mongo
    ports:
      - 8888:8888
    networks:
      - testing-network
    environment:
      SERVICE_D_HOST=service-d
      SERVICE_D_PORT=8080
      DB_HOST = service-a-db
      DB_PORT = 27017

#database for service B
  service-b-db:
    image: mongo
    networks:
      - testing-network

  service-b:
    image: <your-docker-repo-name>/service-b
    restart: always
    depends_on:
      - mongo
    ports:
      - 45000:45000
    networks:
      - testing-network
    environment:
      DB_HOST = service-b-db
      DB_PORT = 27017

#database for service C
  service-c-db:
    image: mongo
    networks:
      - testing-network

  service-c:
    image: <your-docker-repo-name>/service-c
    restart: always
    depends_on:
      - mongo
    ports:
      - 4000:4000
    networks:
      - testing-network
    environment:
      SERVICE_B_HOST=service-b
      SERVICE_B_PORT=45000
      DB_HOST = service-c-db
      DB_PORT = 27017

#database for service D
  service-d-db:
    image: mongo
    networks:
      - testing-network

  service-d:
    image: <your-docker-repo-name>/service-d
    restart: always
    depends_on:
      - mongo
    ports:
      - 8080:8080
    networks:
      - testing-network
    environment:
      SERVICE_B_HOST=service-b
      SERVICE_B_PORT=45000
      SERVICE_C_HOST=service-c
      SERVICE_C_PORT=4000
      DB_HOST = service-d-db
      DB_PORT = 27017

networks:
  testing-network:

Add Docker to GitHub Actions

Now for the final part, we add docker compose file that contain all the service that we need include the tested services.

name: "CI"
on:
  pull_request:
  push:
    branches:
      - master
      - "releases/*"

jobs:
  tests:
    name: "Integration testing"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: "Set up environment"
        run: docker compose -f docker-compose.yml up -d --wait
      - name: "Test server"
        run: docker exec -it service-a-1 yarn test

In this configuration we use docker compose up -d to build the container on the background -d will not freeze the terminal with a bunch of log messages from the docker build. After that we will wait 30 seconds for Docker to finish building. Actually writing a logic like this is not that efficient because maybe it could be faster or slower than 30 seconds. The best practice for this one is to use a while loop and check for a server response so it will exit the loop once the condition is fulfilled with the server response which means the docker build is finished.

After the test environment is ready, we can start our test. In the configuration above, I use yarn test as a command to test a service. So I use command docker exec -it service-a-1 yarn test to execute the test command inside the tested service which in this case is service-a (the name of the container will be followed by -1 as a default so make sure you put it behind your container name).

Conclusion

We can see that the main keypoint of configuration in order to make each service communicate with each other are:

network: make sure it use the same network in every service
host: localhost won't work if it on a remote environment so make sure it use service name instead.

With the power of GitHub Action and docker it can create the test environment on our remote repository so we don't need to deploy other services in order to use it in testing.

Hope you like this content and I'm open for taking feedback about this post so don't hesitate to leave a comment or suggestion. Thanks!😄

Forem: Sahanon Phisetpakasit

How to setup Semantic Release with GitHub Actions.

First Step: Create GitHub's Personal Access Token

Second Step: Setup GitHub token in repository's environment

Third Step: Setup workflows

Fourth Step: Create .releaserc

Final Step: Add, Commit and Push

Conclusion

Reference

Funny mistake when I was using Axios Interceptor.

Setup Docker for integration testing in GitHub Action.

Overview

Setup Github Actions

Create Docker compose for building the service container

Add Docker to GitHub Actions

Conclusion

Fourth Step: Create `.releaserc`