Manually Create Coverage Badges Using GitHub Actions


Adding a coverage badge to your repository is an excellent way to demonstrate your project's test coverage and maintain a high level of code quality. By the end of this guide, you will be able to generate a dynamic coverage badge that updates automatically with each new push to your repository.

## Prerequisites

- A [Node.js](https://nodejs.org/) project with test coverage reports generated by a tool like [c8](https://github.com/bcoe/c8) or [Istanbul](https://github.com/istanbuljs/nyc).
- A GitHub repository for your project.
- [GitHub deploy keys](https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-create-ssh-deploy-key) configured for your repository.

Let's get started!

## Step 1: Install Cheerio

Before anything else, make sure you have a coverage report generated by your testing tool. In our case, we will use the HTML report generated by [c8](https://github.com/bcoe/c8). This report will look something like this:

```html filename=./coverage/index.html
<!DOCTYPE html>
<html lang="en">
  <body>
    <div class="wrapper">
      <div class="pad1">
        <div class="clearfix">
          <div class="fl pad1y space-right2">
            <span class="strong">100%</span>
            <span class="quiet">Statements</span>
            <span class="fraction">786/786</span>
          </div>
          <div class="fl pad1y space-right2">
            <span class="strong">100%</span>
            <span class="quiet">Branches</span>
            <span class="fraction">74/74</span>
          </div>
          <div class="fl pad1y space-right2">
            <span class="strong">90.9%</span>
            <span class="quiet">Functions</span>
            <span class="fraction">33/33</span>
          </div>
          <div class="fl pad1y space-right2">
            <span class="strong">100%</span>
            <span class="quiet">Lines</span>
            <span class="fraction">786/786</span>
          </div>
        </div>
      </div>
    </div>
  </body>
</html>
```

We will use [cheerio](https://github.com/cheeriojs/cheerio), a [jQuery](https://jquery.com/)-like library for server-side to extract the percentage data from the HTML. Install it to your `devDependencies` using the package manager of your choice:

```bash
# npm
npm install --save-dev cheerio

# yarn
yarn add --dev cheerio

# pnpm
pnpm add --save-dev cheerio
```

## Step 2: Create a Script to Extract Coverage Data

Next, we need to create the actual script that will extract the coverage data from the HTML report. Create a new file called `./scripts/generate-badges.js` and add the following code:

```js filename=./scripts/generate-badges.js
const fs = require('fs');
const https = require('https');
const cheerio = require('cheerio');

const coverageFile = './coverage/index.html';
const badgesDir = './coverage/badges';

// Read the coverage HTML file.
fs.readFile(coverageFile, 'utf-8', (err, data) => {
  if (err) {
    console.error(`Error reading coverage file: ${err}`);
    process.exit(1);
  }

  // Parse the HTML using Cheerio.
  const $ = cheerio.load(data);

  // Construct the shields.io URL for each badge.
  const statementsBadgeUrl = generateUrl('statements', extractPercentage($, 1));
  const branchesBadgeUrl = generateUrl('branches', extractPercentage($, 2));
  const functionsBadgeUrl = generateUrl('functions', extractPercentage($, 3));
  const linesBadgeUrl = generateUrl('lines', extractPercentage($, 4));

  // Create the badges directory if it does not exist.
  if (!fs.existsSync(badgesDir)) {
    fs.mkdirSync(badgesDir);
  }

  // Download each badge and save it to the badges directory.
  downloadBadge(statementsBadgeUrl, `${badgesDir}/statements.svg`);
  downloadBadge(branchesBadgeUrl, `${badgesDir}/branches.svg`);
  downloadBadge(functionsBadgeUrl, `${badgesDir}/functions.svg`);
  downloadBadge(linesBadgeUrl, `${badgesDir}/lines.svg`);

  console.log('Code coverage badges created successfully.');
});

/**
 * Generate a shields.io URL for a badge.
 *
 * Change the color of the badge based on the percentage.
 *
 * @param {string} text The text to display on the badge.
 * @param {number} percentage The percentage to display on the badge.
 * @returns {string} The shields.io URL.
 */
const generateUrl = (text, percentage) => {
  let color = 'brightgreen';
  if (percentage < 70) {
    color = 'red';
  } else if (percentage < 80) {
    color = 'yellow';
  } else if (percentage < 90) {
    color = 'orange';
  }
  return `https://img.shields.io/badge/coverage%3A${text}-${percentage}%25-${color}.svg`;
};

/**
 * Extract the code coverage percentage from the HTML.
 * @param {Cheerio} $ The Cheerio object.
 * @param {number} index The index of the element to extract.
 */
const extractPercentage = ($, index) => {
  const text = $(`.pad1y:nth-child(${index}) span.strong`) ?? '0';
  const percentage = text.text().trim().replace('%', '');
  return parseFloat(percentage);
};

/**
 * Download a badge from shields.io.
 * @param {string} url The shields.io URL.
 * @param {string} filename The filename to save the badge to.
 */
const downloadBadge = (url, filename) => {
  https.get(url, (res) => {
    if (res.statusCode !== 200) {
      console.error(`Error downloading badge: ${res.statusMessage}`);
      return;
    }

    const file = fs.createWriteStream(filename);
    res.pipe(file);
    file.on('finish', () => {
      file.close();
    });
  });
};
```

This is a fairly straightforward script that uses Cheerio to parse the HTML report and extract the coverage data. It then uses the data to generate the [shields.io](https://shields.io/) URLs for each badge type. Finally, it downloads each badge and saves it to the `./coverage/badges` directory.

Update your `package.json` to add a new script that will run the `generate-badges.js` script:

```json filename=package.json
{
  "scripts": {
    // ...
    "generate-badges": "node ./scripts/generate-badges.js"
  }
}
```

Run the script to generate the badges:

```bash
# generate the coverage report first
pnpm coverage

# generate the badges
pnpm generate-badges
```

## Step 3: Configure GitHub Actions

> **NOTE**: For this guide, we will use [pnpm](https://pnpm.io/), but the commands should be similar for other package managers.

> **NOTE**: This requires that you have an SSH Deploy Key configured for your repository. See [Create SSH Deploy Key](https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-create-ssh-deploy-key) for more information.

In your repository, create a `.github/workflows` directory if it doesn't already exist. Then, create a new YAML file inside the workflows directory called `coverage-badge.yml`. This file will define the GitHub Actions workflow that generates the coverage badge.

Add the following content to `coverage-badge.yml`:

```yaml filename=.github/workflows/coverage-badge.yml
name: (main) coverage badge

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  coverage-badge:
    strategy:
      matrix:
        os:
          - ubuntu-latest
        node:
          - 18.14.2
        pnpm:
          - 7
    runs-on: ${{ matrix.os }}
    steps:
      - name: checkout repository
        uses: actions/checkout@v3
      - name: setup node
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node }}
      - name: install pnpm
        uses: pnpm/action-setup@v2
        id: pnpm-install
        with:
          version: ${{ matrix.pnpm }}
          run_install: false
      - name: get pnpm store directory
        id: pnpm-cache
        shell: bash
        run: |
          echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT
      - name: Setup pnpm cache
        uses: actions/cache@v3
        with:
          path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-
      - name: install dependencies
        run: pnpm install
      - name: run coverage
        run: pnpm coverage
      - name: generate badges
        run: pnpm generate-badges
      - name: push coverage artifacts to another branch
        uses: peaceiris/actions-gh-pages@v3
        with:
          deploy_key: ${{ secrets.COVERAGE_DEPLOY_KEY }}
          publish_dir: ./coverage
          publish_branch: coverage
          allow_empty_commit: true
```

Let's break down the workflow into its various sections:

```yaml
on:
  workflow_dispatch:
  push:
    branches:
      - main
```

The workflow is triggered when there's a push to the `main` branch or can be triggered manually ([`workflow_dispatch`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)).

```yaml
jobs:
  covera:
    strategy:
      matrix:
        os:
          - ubuntu-latest
        node:
          - 18.14.2
        pnpm:
          - 7
    runs-on: ${{ matrix.os }}
```

We're using a matrix strategy to run the workflow on multiple operating systems, Node.js versions, and pnpm versions. For our purpose, we will only use one version of each, but this is a good practice to follow.

```yaml
- name: checkout repository
  uses: actions/checkout@v3
- name: setup node
  uses: actions/setup-node@v3
  with:
    node-version: ${{ matrix.node }}
```

This step checks out your repository using the [actions/checkout](https://github.com/actions/checkout) action. Then, it sets up Node.js using the [actions/setup-node](https://github.com/actions/setup-node) action.

```yaml
- name: install pnpm
  uses: pnpm/action-setup@v2
  id: pnpm-install
  with:
    version: ${{ matrix.pnpm }}
    run_install: false
```

This step installs pnpm using the [pnpm/action-setup](https://github.com/pnpm/action-setup) action and the specified pnpm version from the matrix. We're not installing any dependencies yet, so we don't need to run `pnpm install`.

```yaml
- name: get pnpm store directory
  id: pnpm-cache
  shell: bash
  run: |
    echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT
- name: Setup pnpm cache
  uses: actions/cache@v3
  with:
    path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
    key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
    restore-keys: |
      ${{ runner.os }}-pnpm-store-
- name: install dependencies
  run: pnpm install
```

These steps will use the cache from [actions/cache](https://github.com/actions/cache) and install the project's dependencies using pnpm. We're using the cache to reduce installation time and to avoid downloading the same dependencies multiple times.

```yaml
- name: run coverage
  run: pnpm coverage
- name: generate badges
  run: pnpm generate-badges
```

This step runs the `coverage` script, which should generate a coverage report. Then, it runs the `generate-badges` script, which should generate the coverage badges.

```yaml
- name: push coverage artifacts to another branch
  uses: peaceiris/actions-gh-pages@v3
  with:
    deploy_key: ${{ secrets.COVERAGE_DEPLOY_KEY }}
    publish_dir: ./coverage
    publish_branch: coverage
    allow_empty_commit: true
```

Lastly, this step pushes the coverage artifacts, including the generated badges and the coverage report, to a separate coverage branch in your repository using the [peaceiris/actions-gh-pages](https://github.com/peaceiris/actions-gh-pages) action.

Options:

- The `deploy_key` option is set to the `COVERAGE_DEPLOY_KEY` secret, which is a Deploy Key stored in your repository settings. This deploy key should have write access to the repository. Follow the instructions from [Create SSH Deploy Key](https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-create-ssh-deploy-key) to generate it and add it to your repository.
- The `publish_dir` is set to `./coverage`, which is the directory containing the coverage report and badges.
- The `allow_empty_commit` option is set to true to allow empty commits if there are no changes in the coverage artifacts.
- The `publish_branch` is the name of the branch you want to push the coverage artifacts to. It's currently set to `coverage`, but you can change it to whatever you want.

## Step 4: Add Badge to README

To display the coverage badge in your README file, add the following line at the top of your `README.md` file:

```md filename=README.md
![Coverage: Statements](https://raw.githubusercontent.com/<USER_NAME>/<REPO_NAME>/<PUBLISH_BRANCH_NAME>/badges/statements.svg)
![Coverage: Branches](https://raw.githubusercontent.com/<USER_NAME>/<REPO_NAME>/<PUBLISH_BRANCH_NAME>/badges/branches.svg)
![Coverage: Functions](https://raw.githubusercontent.com/<USER_NAME>/<REPO_NAME>/<PUBLISH_BRANCH_NAME>/badges/functions.svg)
![Coverage: Lines](https://raw.githubusercontent.com/<USER_NAME>/<REPO_NAME>/<PUBLISH_BRANCH_NAME>/badges/lines.svg)
```

These lines will render the badges as an image. It should point to the latest badges in your `<PUBLISH_BRANCH_NAME>` branch.

## Conclusion

Congratulations! You have successfully created a dynamic coverage badge for your Node.js project. This badge will help you showcase your project's test coverage and encourage you to maintain a high level of code quality. Don't hesitate to customize this workflow to suit your needs and adapt it to different coverage tools and badge styles.

Happy coding!


Copy Issue Labels From Another GitHub Repository


If you manage multiple projects across different GitHub Organizations, you may have faced a common scenario: the need to copy [GitHub issue labels](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels) from one repository to another. It used to be a manual process before, but luckily we can now use [GitHub's official CLI](https://cli.github.com/).

## Why copy issue labels?

Here are some common scenarios when you might need to copy issue labels between projects:

- **Standardization**: If your Organization requires a standard list of issue labels for all projects, copying issue labels from an existing project with the required labels ensures consistency.
- **Project Migration**: When a project is moved from one Organization to another, you might want to retain the issue labels to maintain the same workflow and issue categorization.
- **Team Collaboration**: If multiple teams within an Organization work on similar projects, having a unified set of issue labels for better collaboration and understanding across teams is helpful.

## Using the GitHub CLI

Before we dive into the process, make sure you have the GitHub CLI installed on your system. If you haven't installed it yet, head to https://cli.github.com/ and follow the installation instructions for your operating system.

You can authenticate with the CLI using:

```bash
gh auth login
```

Once you have the GitHub CLI installed and configured, you can copy issue labels between repositories by executing the following command:

```bash
gh label clone owner-name/source-repo-name --repo owner-name/destination-repo-name --force
```

Here's a breakdown of the command:

- `gh`: The GitHub CLI command.
- `label`: The command group for working with issue labels.
- `clone`: The command to copy labels from one repository to another.
- `owner-name/source-repo-name`: The source repository from which you want to copy the issue labels.
- `--repo`: The flag to specify the destination repository to which the issue labels will be copied.
- `owner-name/destination-repo-name`: The destination repository to which the issue labels will be copied.
- `--force`: Optional flag to overwrite existing labels in the destination repository.

Documentation for the command can be found at https://cli.github.com/manual/gh_label_clone.

> **NOTE**: Please note that you must have the necessary permissions (write access) for the destination repositories.

Once the command executes successfully, all issue labels from `owner-name/source-repo-name` will be copied to `owner-name/destination-repo-name`, ensuring that the latter now follows the Organization's standard list of issue labels.

## Creating default labels for your Organization

As an Organization owner, you can also create default labels that will be automatically included in every new repository in your Organization. This is a convenient way to standardize issue labels across all projects within your Organization.

Please refer to the GitHub documentation on [Managing Default Labels for Repositories in Your Organization](https://docs.github.com/en/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization) for detailed instructions and screenshots.

> **NOTE**: Adding, editing, or deleting a default label does not affect existing repositories. Default labels only apply to new repositories created after the changes.


Deploying a Repository Inside a GitHub Organization to Vercel Using GitHub Actions


[Vercel](https://vercel.com/) is a popular cloud service platform designed for hosting [Next.js](https://nextjs.org/) applications. While it offers free hosting for personal repositories, it doesn't allow deploying from repositories inside a GitHub Organization unless you subscribe to a paid plan.

In this blog post, we'll create a GitHub Action that duplicates the content of a repository inside a GitHub Organization to a repository in your personal GitHub account, allowing you to leverage Vercel's free hosting services.

> **NOTE**: This approach may not be suitable for all scenarios, and ensuring proper security measures when dealing with sensitive data is essential.

## Prerequisites

- A personal GitHub account
- A repository within a GitHub Organization (source repository)
- A separate repository in your personal account to host the copied files (destination repository)

## Step 1: Generate SSH Keys

You'll need to generate an SSH Deploy Key to securely push your content from the organization's repository to the external repository. Although you can also use a Personal Access Token, an SSH deploy key is recommended as it minimizes the impact of potential security breaches.

```bash
ssh-keygen -t ed25519 -C "$(git config user.email)" -N "" -f github-<desitination-repo-name>
```

Replace the `<desitination-repo-name>` with the name of your destination repository and run the command. Afterwards, you should now have both public and private key files:

- `github-<desitination-repo-name>.pub` (public)
- `github-<desitination-repo-name>` (private)

## Step 2: Add the private key to the Source Repository

1. Visit the source repository's GitHub page.
2. Click on "Settings" in the repository (not account settings).
3. In the left-hand pane, click "Secrets", then "Actions".
4. Click on "New repository secret".
5. Name it `SSH_DEPLOY_KEY` and paste the contents of the private key file.
6. Click "Save".

## Step 3: Add the public key to the Destination Repository

1. Visit the destination repository's GitHub page.
2. Click on "Settings" in the repository (not account settings).
3. In the left-hand side pane, click on "Deploy keys."
4. Click on "Add deploy key".
5. Paste the contents of the public key file.
6. Enable "Allow write access".
7. Click "Save".

## Step 4: Disable GitHub Actions on the Destination Repository

1. Visit the destination repository's GitHub page.
2. Click on "Settings" in the repository (not account settings).
3. Click on "Actions" and then "General".
4. Select "Disable actions".
5. Click "Save".

## Step 5: Create a GitHub Action Workflow

Create a new GitHub Action workflow in your source repository by adding a YAML file in the `.github/workflows` directory. Name the file `push-to-external-repo.yml` and paste the following content:

```yaml filename=.github/workflows/push-to-external-repo.yml
name: (main) push to external repo
on:
  push:
    branches:
      - main
jobs:
  push-to-external-repo:
    runs-on: ubuntu-latest
    steps:
      - name: checkout repository
        uses: actions/checkout@v3
      - name: push to external repository
        uses: peaceiris/actions-gh-pages@v3
        with:
          deploy_key: ${{ secrets.SSH_DEPLOY_KEY }}
          publish_dir: .
          external_repository: <your-username>/<destination-repo-name>
          publish_branch: main
          allow_empty_commit: true
```

Replace `<your-username>` with your GitHub username and `<destination-repo-name>` with the name of the external repository in your personal account.
This action will copy everything from your organization's repository to your personal repository, including your GitHub Action workflows, so follow [Step 4](#step-4-disable-github-actions-on-the-destination-repository) to disable GitHub Actions on the destination repository.

## Step 6: Run your workflow

Push something to your `main` branch and see it be pushed to your `<your-username>/<destination-repo-name>` repository.

## Step 7: Set up a project on Vercel

1. On Vercel's "New Project" page, choose the account linked to the project under the "Import Git Repository" section.
2. Find your personal repository in the list and select "Import".
3. Vercel will automatically detect the framework and any necessary build settings. You can configure project settings, including build and development settings and environment variables, at this stage or later.
4. Click the "Deploy" button. Vercel will create the project and deploy it based on the chosen configurations.


Nap Joseph Calub

Posts with the "GitHub" tag