DEV Community: skywarth

How I built my first bot using Typescript - Part #4: Deployment and CI/CD

skywarth — Fri, 30 Aug 2024 16:08:03 +0000

Hi everyone,

This the part #4 of the series, make sure to check the rest of them! Here's the previous episode.

Recently I've published a GitHub app on GitHub marketplace. Darkest-PR is a bot for responding to the actions occurring in your repository by commenting them with quotes from the Darkest Dungeon game. The goal was to make development more fun and enjoyable thanks to the narrations by the Darkest-PR.

In this episode, we'll discover the developments and decisions made for this app regarding the deployment and CI/CD aspects.

Episodes:

Beginning and architecture
Unit and feature testing, mocking & spying
Code coverage reports
Deployment and CI/CD (you're here!)
Publishing and final remarks

Don't forget to check the repository if you'd like to follow along!

What is CI/CD?

CI/CD stands for Continuous Integration and Continuous Deployment. It’s a methodology used to streamline the development process by automating the build, testing, and deployment stages of a project.

Continuous Integration (CI): This is the practice of automatically integrating code changes into a shared repository several times a day. Each integration is verified by an automated build and tests, allowing me to catch issues early. Tools like GitHub Actions, Jenkins, and Travis CI are commonly used for CI.

Continuous Deployment (CD): After the code passes all tests and meets quality checks, it’s automatically deployed to a production environment. This reduces manual intervention, making the deployment process faster and more reliable. Vercel, Netlify, and AWS Amplify are examples of CD tools.

In the context of Darkest-PR:

CI tasks include:

Checking out the project (cloning) uses: actions/checkout@v4
Setting up Node.js environment uses: actions/setup-node@v3
Installing dependencies npm ci
Building the app npm run build
Running unit tests and generating coverage reports npm test -- --coverage
Uploading code coverage reports to CodeCov uses: codecov/codecov-action@v4.0.1

CD tasks include:

Deploying the app to Vercel as serverless deployment

Setting Up CI with GitHub Actions

GitHub Actions is the CI/CD tool I used for Darkest-PR. It allows me to automate tasks like testing and building the app whenever I push code to the repository.

Here's the GitHub action workflow yaml file:

# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node

name: Node.js CI

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build
    - run: npm test -- --coverage
    - name: Upload coverage reports to Codecov
      uses: codecov/codecov-action@v4.0.1
      with:
       token: ${{ secrets.CODECOV_TOKEN }}

Let’s break down what this file does:

Trigger Events: The workflow triggers on any push or pull request to the master branch.
Job Setup: It runs on an ubuntu-latest environment and tests the project using Node.js version 18.x. Steps:
Checkout Code: It pulls the latest code from the repository.
Setup Node.js: It installs the specified Node.js version and caches npm dependencies.
Install Dependencies: It installs the project dependencies using npm ci.
Build the Project: It builds the source code.
Run Tests: It runs tests and generates a coverage report.
Upload Coverage: It uploads the coverage report to Codecov for analysis.

This setup ensures that the project is always tested and built in a clean environment, catching any issues before they reach production.

Deploying to Vercel

For deployment, I use Vercel’s free tier, which offers free serverless deployment. The app is deployed by creating serverless function definitions that Vercel uses to run the app.

Here’s the code from my deployment setup, Vercel API Endpoint: Located in /api/github/webhooks/index.ts:

import {createNodeMiddleware, createProbot} from "probot";
import app from "../../../src/index.js";

const probot = createProbot();

export default createNodeMiddleware(app, {
    probot,
    webhooksPath: "/api/github/webhooks",
});

This file defines the API endpoint that Vercel will deploy. It uses Probot to handle GitHub webhooks, allowing the app to listen to events from the repositories it’s installed on.

Whenever I push code to the master branch, the CI workflow is triggered, running all tests and generating coverage reports. If everything passes, the app is then deployed to Vercel automatically, ensuring that the latest version is always live.

Conclusion

By integrating CI/CD into Darkest-PR, I’ve automated the build, testing, and deployment process, making the development workflow smoother and more efficient. GitHub Actions handles the CI tasks, while Vercel takes care of the CD side, providing a seamless deployment experience.

And it is a wrap! In the next chapter we will talk about the publishing of the app. GitHub Marketplace, ProductHunt and many more will be explored upon, so stay tuned.

How I built my first bot using Typescript - Part #3: Code Coverage Reports

skywarth — Wed, 21 Aug 2024 11:55:19 +0000

Hi everyone,

This the part #3 of the series, make sure to check the rest of them! Here's the previous episode.

Recently I've published a GitHub app. Darkest-PR is a bot for responding to the actions occurring in your repository by commenting them with quotes from the Darkest Dungeon game. The goal was to make development more fun and enjoyable thanks to the narrations by the Darkest-PR.

For this episode, I'll be covering code coverage reports, deployment and CI/CD operations of the app.

Episodes:

Beginning and architecture
Unit and feature testing, mocking & spying
Code coverage reports (you're here!)
Deployment and CI/CD
Publishing and final remarks

Don't forget to check the repository if you'd like to follow along!

Code Coverage

What is code coverage?

Code coverage is a metric that is used to measure the percentage and the sections of code that are subject to unit/feature testing. If any of your unit tests hits a certain line in a file at any point during testing, then that line has been successfully covered by tests.

Unit of code coverage is percentage (%). Higher it is, better it is. Because higher code coverage means sufficient amount of tests are prepared to cover those sections of the code. By my experience, for commercial applications your code coverage should be at least 50% , that is the vital minimum amount, anything below that means you're shooting in the dark and may encounter bugs at any time. For open-source projects and especially libraries, you should aim for around 95% coverage, 90% as minimum. Because libraries are meant to be used by hundreds if not thousands of projects, so if anything goes wrong in your library it will affects all those projects, teams and their users. So be a responsible open-source developer and prepare sufficient unit tests to reach at least %90 coverage.

In theory; higher the code coverage amount, unlikely you're to encounter unexpected bugs. While high code coverage doesn’t guarantee bug-free code, it does give you confidence that a significant portion of your code is being tested, helping to catch potential issues early in the development process.

Types of Code Coverage

Before diving into the specifics of how we handle code coverage in Darkest-PR, let’s quickly go over the different types of code coverage:

Line Coverage: Measures the percentage of lines of code that have been executed during tests.
Branch Coverage: Focuses on the decision points in your code, ensuring that every possible branch (e.g., if/else statements) is tested.
Function Coverage: Tracks whether each function in your codebase has been called during the testing process.
Statement Coverage: Similar to line coverage but focuses on individual statements rather than lines.

How to generate code coverage reports

There are various methods and frameworks for generating code coverage reports, it all depends on your tech stack. Some famous code coverage report generation tools:

V8
- Javascript/Node.js
- Node.js built in test coverage engine
- Node.js has built-in V8 code coverage support, which generates detailed code coverage reports in JSON format. These reports can be converted to more readable formats (e.g., HTML) using tools like c8 or v8-to-istanbul.
Istanbul.js
- JavaScript/TypeScript
- Provides code coverage reports for JavaScript applications, directly generating detailed HTML, JSON, and text reports.
PHPUnit
- PHP
- A testing framework for PHP that also generates code coverage reports in formats like HTML and XML.
Clover
- Java/Groovy
- Generates detailed code coverage reports for Java and Groovy projects, with output in HTML, XML, and JSON.

And the list goes on. For each language there are dozens of test coverage engines to choose from. You should evaluate each one's pros and cons and deduce it per your requirements.

For this project I went along with V8. I tried Istanbul engine too but I liked the performance and metrics of V8 more. Here's what output Vitest with V8 provides us in CLI:

In the output above, we can clearly see which file has what percentage of coverage, and which files are lacking code coverage.

When you run vitest --coverage it will automatically create a /coverage folder in your repository's root. This folder contains your coverage reports in various formats. XML, JSON and HTML. For demonstration purposes you may open the index.html file in a browser to see the report yourself.

You can also try vitest --ui for interactive code coverage report webpage.

Each of these code coverage reports (XML, JSON, HTML) contains the same coverage analysis but in different formats. In the next title, we'll explore how we can use these reports to publish them publicly and consistently.

SaaS tool for publishing coverage reports for free

After being able to generate code coverage reports, now we can move on to publishing them on an online platform so these reports will be accessible anywhere anytime.

CodeCov is a SaaS tool for uploading and visualizing your code coverage reports. It is free for open-source projects. It enables visually compelling charts to be displayed for your reports.

Moreover, CodeCov also offers support for Markdown badges so you can easily embed your coverage percentage to your repository.

Simply login with your GitHub profile and add your repository to CodeCov. Afterwards you need to automatically relay code coverage reports whenever it is generated. Now you might ask: "Why, how am I supposed to send it to CodeCov if I generate it locally?" That is simple, you need to setup a CI/CD pipeline to:

Clone project
Install dependencies
Build the project
Run tests and & generate code coverage reports
Send generated coverage reports to CodeCov

CodeCov has a GitHub action to easily send reports, it is called codecov/codecov-action.

Here's the CI/CD action file for the project which reflects the steps mentioned above:

name: Node.js CI

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x]

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build
    - run: npm test -- --coverage
    - name: Upload coverage reports to Codecov
      uses: codecov/codecov-action@v4.0.1
      with:
       token: ${{ secrets.CODECOV_TOKEN }} #add your CodeCov secret to repository secrets!

And after this, whenever a push occurs or a PR is created for master; our code coverage reports will be submitted to CodeCov automatically and the metrics will always be up-to-date.

How I built my first bot using Typescript - Part #2: Unit testing, mocking and spying

skywarth — Fri, 16 Aug 2024 00:30:26 +0000

Hi everyone,

This the part #2 of the series, make sure to check the rest of them! Here's the first part.

In this episode, we'll delve into unit testing and feature testing for my Probot app built with Typescript. We'll be using Vitest as testing framework.

Episodes:

Beginning and architecture
Unit and feature testing, mocking & spying (you're here!)
Code coverage reports
Deployment and CI/CD
Publishing and final remarks

Don't forget to check the repository if you'd like to follow along!

Enacting TDD early on

One thing I wanted to do in this project was to enact Test-Driven-Development early on, because in TDD you're meant to embrace it in the earlier phases of the project otherwise you wouldn't fully benefit from it. In TDD; you're meant to write tests first, then implement the feature. It's like shoot first ask questions later 😄, but in a better way. In TDD, when you write tests cases first, it is expected to be failing, since the feature is not implemented yet. It is the expected flow of TDD. Writing the unit/feature tests that are failing but includes all the necessary assertions per requirements of the feature. Then you write the implementation to accommodate the test requirements, to make it pass.

Hence I embraced TDD in this project, as early as when the first skeleton of the architecture took form. And what a great decision it was! Because at certain points I made drastic changes, altering decision, or encountered force-majeures which forced my hand to adjust my approach. In such cases I once again found the bliss of TDD. There wasn't tech debt or refactoring cost associated with changes because after each change I was able to run all tests easily and see whether any of the test cases were failing or not. This made the refactoring so much more productive than usual. Development costs were cut significantly.

Structuring tests

First thing I did before rushing for writing test cases, was to define a clean hierarchy and structure for tests. For starters I elected to have both unit and feature tests, but no integration tests. Also we are going to have certain test data, or 'fixtures' as it is usually called. It would also make sense to distinguish certain modules/classes under distinct folders to categorize them. And the most important of them all, a boilerplate for tests. I usually prepare a boilerplate for my test cases in each project. Test case boilerplates helps you have some sort of inheritance/abstraction, enabling you to have control over all of the test, since they inherit or implement this boilerplate. We'll get to that later on don't worry, in the next section. And ta-da! Here's the final structure for tests

Deep dive into mocking and spying

Prior to this project I've done many unit testing for various projects of mine. Different languages and frameworks. Now I wanted to see what Vitest offered in terms of mocking and spying. So bit by bit, demo by demo by I started the grasp the concept and how to apply it in Vitest. Here's my key-notes for them:

Mocking: you "mock" a function, alter/define its implementation to fit your agenda. Function, not method.
Spying: you "spy" a method, method of a class or an object. Alter/define its implementation.

Mocking/spying allow you to register calls and responses. It also enables you to implement them numerous times as needed. It is actually such a strong capability.

I've applied mocking and spying vigorously to see the full extent of its power.

Here's the content of my unit testing stub (or abstract class) which contains all references to mocking and spying:

export class StrategyTestSetup {
    probot!: Probot;
    quoteFacadeGetQuoteSpy!: MockInstance;
    commentFactoryCreateSpy!: MockInstance;
    actionStrategyHandleSpy!: MockInstance;
    createCommentEndpointMock: Mock=vi.fn();
    pullRequestIndexResponseMock: Mock=vi.fn();
    pullRequestReviewIndexResponseMock: Mock=vi.fn();
    getConfigResponseMock: Mock=vi.fn();

    initializeMocks() {
        this.probot = new Probot({
            githubToken: "test",
            Octokit: ProbotOctokit.defaults(function(instanceOptions: any) {
                return {
                    ...instanceOptions,
                    retry: { enabled: false },
                    throttle: { enabled: false },
                };
            }),
        });
        DarkestPR(this.probot);

        this.quoteFacadeGetQuoteSpy = vi.spyOn(QuoteFacade.prototype, 'getQuote');
        this.commentFactoryCreateSpy = vi.spyOn(CommentFactory.prototype, 'create');
        this.createCommentEndpointMock.mockImplementation((param: any) => param);
        this.pullRequestIndexResponseMock.mockImplementation(()=>[]);//default implementation
        this.getConfigResponseMock.mockImplementation(()=>({}));//default implementation
    }

    setupEndpointMocks() {
        const endpointRoot: string = 'https://api.github.com';
        const owner:string='test-owner';
        const repo:string='test-repo';


        const pullNumber:number=555444;

        nock(endpointRoot)
            .persist()
            .get(`/repos/${owner}/${repo}/pulls`)
            .query(true)
            .reply(200, this.pullRequestIndexResponseMock);

        nock(endpointRoot)
            .persist()
            .post(`/repos/${owner}/${repo}/issues/${pullNumber}/comments`, this.createCommentEndpointMock)
            .reply(200);

        nock(endpointRoot)
            .persist()
            .get(`/repos/${owner}/${repo}/contents/.darkest-pr.json`)
            .reply(200, ()=>{
                return {
                    content: Buffer.from(JSON.stringify(this.getConfigResponseMock())).toString('base64')
                }
            });

        nock(endpointRoot)
            .persist()
            .get(`/repos/${owner}/${repo}/pulls/${pullNumber}/reviews`)
            .reply(200, this.pullRequestReviewIndexResponseMock);
    }

    beforeAll() {
        nock.disableNetConnect();
        this.initializeMocks();
        this.setupEndpointMocks();
    }

    afterEach() {
        vi.clearAllMocks();
    }


    performCommonAssertions(expectedCaseSlug:string):{comment:Comment}{
        expect(this.actionStrategyHandleSpy).toHaveBeenCalled();
        expect(this.quoteFacadeGetQuoteSpy).toHaveBeenCalled();
        expect(this.commentFactoryCreateSpy).toHaveBeenCalled();
        const commentInstance = this.commentFactoryCreateSpy.mock.results[0].value;
        expect(commentInstance).toBeInstanceOf(Comment);
        expect(commentInstance.caseSlug).toBe(expectedCaseSlug);

        const sentData = this.createCommentEndpointMock.mock.results[0]?.value ?? {};
        expect(this.createCommentEndpointMock).toHaveBeenCalledOnce();
        expect(sentData).toHaveProperty('body');
        expect(sentData.body).toBeTypeOf('string');
        expect(sentData.body.length).toBeGreaterThan(0);
        return {
            comment:commentInstance
        };
    }
}

Base test class

If you ever wrote unit/feat tests for a class/service, then you know the hassle about redundant code sections and declarations. Since Darkest-PR contains multiple strategy pattern implementations it was paramount to have a base test class which all other tests will extend from. This would enable centralized control over all the tests, and refactoring cost would be greatly reduced. Hence I prepared the StrategyTestSetup base test class which is responsible for setting up test environment before commencing tests. You may have base test class, or stub, or abstract test class for:

Common setup operations for test environment
Clean-up operations after each test
Assertions and evaluations that are common for each test

For these reason, it is a great idea to have a base test class where all other (or certain group of) tests inherit or include from.

Thanks to the StrategyTestSetup base test class, now each of my strategy tests looks like this which is super simple and straight forward:

Further reducing duplicate code

To eliminate duplicate code and redundancy, you should also use .each() feature of Vitest whenever possible. .each() can be applied to groups, describe() statements and test() statements. It is really flexible extension that allows you to loop tests and feed them predefined inputs. See it in action:

describe("Pull Request opened tests", () => {
    const strategyTestSetup = new StrategyTestSetup();

    beforeAll(() => {
        strategyTestSetup.beforeAll();
    });

    afterEach(() => {
        strategyTestSetup.afterEach();
    });
    describe.each([
        {
            description: "No previous PRs",
            previousPrs: [],
            expectedCaseSlug: CaseSlugs.PullRequest.Opened.Fresh,
        },
        {
            description: "Previously not merged (closed)",
            previousPrs: pullRequestListNotMerged,
            expectedCaseSlug: CaseSlugs.PullRequest.Opened.PreviouslyClosed,
        },
        {
            description: "Previously merged",
            previousPrs: pullRequestListMerged,
            expectedCaseSlug: CaseSlugs.PullRequest.Opened.PreviouslyMerged,
        },
    ])('$description', ({ previousPrs, expectedCaseSlug }) => {
        test('Creates a comment after receiving the event', async () => {
            strategyTestSetup.actionStrategyHandleSpy = vi.spyOn(PullRequestOpenedStrategy.prototype as any, 'handle');
            strategyTestSetup.pullRequestIndexResponseMock.mockImplementation(() => previousPrs);
            await strategyTestSetup.probot.receive({
                id: '123',
                name: 'pull_request',
                payload: pullRequestOpenedPayload as any,
            });
            strategyTestSetup.performCommonAssertions(expectedCaseSlug);
            expect(strategyTestSetup.pullRequestIndexResponseMock).toHaveBeenCalledOnce();
        });
    });
});

And with these gains, and total of 90 test cases written, we conclude the test section of the project. In the next chapter we'll cover the CI/CD and test coverage aspect of the project so stay tuned!

How I built my first bot using Typescript

skywarth — Mon, 12 Aug 2024 13:21:15 +0000

Hi everyone,

In this post series, I'm going to explain how I built my first GitHub app, what was the important lessons that I've learnt, what secrets I've discovered and how you can do the same!

These series will be separated into episodes/parts so you can follow the journey easily.

Episodes:

Beginning and architecture (you're here!)
Unit and feature testing, mocking & spying
Code coverage reports
Deployment and CI/CD
Publishing and final remarks

Don't forget to check the repository if you'd like to follow along!

Prologue

Prior to this project I haven't practiced or used Typescript extensively. I knew how it operated and the differences of it with JS but never used it properly in a project. I've primarily used vanilla JS for years and had no problem with run-time debugging, type-safety or type-hinting. Therefor never really had a craving for Typescript.
After deciding to build a GitHub app/bot, and discovering the Probot framework, during the installation I was asked whether to install framework for JS or Typescript. Since I wanted to experiment with it for a long while, I said hell why not and choose Typescript. I also wanted to experiment on the OOP and design pattern capabilities of the TS, to see it firsthand. So that's how and why I choose TS for this project.

Goal

The goal was to develop a bot. I wanted this bot to respond with quotes specifically from Darkest Dungeon game.

I've always enjoyed roguelike, dungeon-crawler and RPG games. Among all those games many, Darkest Dungeon has a special place in my heart. In no such game I've encountered such captivating, strong, profound and invested monologues. Both the audio and the narration scripts are spectacular. It is so Shakespearean. Another reason I keep it so dear is that it's stress, hope, despair, loss mechanics are unique. It really makes you connected with the game, as if you're feeling the actual moments your characters are going through, the ambiance is riveting. The first time you get party-wiped, you learn the true meaning of desperation and the setting of the game. It's like Dark Souls of dungeon crawlers.

Fun fact: I unconsciously memorized 90% of all the quotes from Darkest Dungeon.

In my career, I've reviewed thousands upon thousands pull requests. Countless issues, bugs tackled. Worked with my fellow teammates to undertake many challenging features. Each of these feature a different setting of emotions; some of them are definitive struggles, some a gentle breeze, some terrorizing nightmares, some are well-deserved relief after completing them.

Then I realized, each development is very similar to Darkest Dungeon runs. Your team is your party, your environment is your location, your task/goal is your adversary. So it would be apt to narrate the development like so.

And for this reason, Darkest-PR has come to life. To make development process more interactive, more fun, more story-like, an epic tale.

Humble beginnings

After performing some research on how a GitHub app operates, without long I stumbled upon Probot. Probot is a framework for building GitHub applications using TS or JS. It has extensive documentation and handles all the nifty details which you might find daunting at first like: authentication, API keys, API security etc. After seeing how easy it would be using Probot, I decided to use it.

I've initialized the project with npx create-probot-app my-first-app command and filled in the questionnaire by the CLI:

Let's create a Probot app!
? App name: Darkest-PR
? Description of app: A 'Hello World' GitHub App built with Probot.
? Author's full name: John Doe
? Author's email address: john@doe.com
? GitHub user or org name: skywarth
? Repository name: Darkest-PR
? Which template would you like to use? (Use arrow keys)
  basic-js
❯ basic-ts (use this one for TypeScript support)
  checks-js
  git-data-js
  deploy-js

Finished scaffolding files!

Installing dependencies. This may take a few minutes...

Successfully created my-first-app.

Begin using your app with:
  cd my-first-app
  npm start

View your app's README for more usage instructions.

Visit the Probot docs:
  https://probot.github.io/docs/

Get help from the community:
  https://probot.github.io/community/

Enjoy building your Probot app!

And there it was, the first step.

Architecture

Being a software engineer, I have a strong appetite for designing the architecture of software systems. What are the requirements? What are the limitations? What do we strive for? Anyone who's ever done systems designs can tell what I'm talking about here. Functional and non-functional requirements of the system is to be determined. Later I've moved on to choose the infrastructure and establish data flow. This is high level design. Thanks to Probot, most of these are already established and decided for so there is not much of a high level design to be made.

So I moved on to low-level-design, the LLD. My first priority here was to determine the technologies, platforms and most importantly the design patterns I'll be using. It is important to determine these beforehand, before you write a single line of code because they drastically change the course of the project. These are the patterns I've elected to go along with:

Repository pattern

This is for the abstraction of data. Since 'quotes' in the app are constant and technically a data source, I decided to apply the principle of abstraction because even though currently it is loaded from a JSON file, I might decide to move them to a MySQL database, or a CouchDB, or a NoSQL database, or maybe even load them straight from variables in code. Who knows? To be prepared for these kind of challenges, and to make these transitions smooth you need to apply repository pattern. But keep in mind I didn't apply it just because of a 'if', I applied it because it is likely to change. Don't use patterns blindly or out of mere possibility, there should be a likelihood.

Strategy pattern

According to my requirement analysis, the app needs to respond to various events occurring in the user's GitHub repository. Such as PR opened, PR closed, Issue assignment, assignment removal, approval etc. Dozen events to begin with. And there could be more to come in the future. And to each of these events the app has to respond with a comment, that is the bottom line of it. Each event features a different data payload received from the webhook. Moreover, each of these events bear a different contextual emotion matrix so a fitting quote can be made for it. Essentially, each is a different strategy. Hence the strategy pattern. It is a good use-case for using strategy pattern. So I developed a structure and various abstraction to accommodate the need for various event handlers and in the end it fit perfectly for the mechanism. It allowed for a clean architecture and easy time debugging, changes were smooth if required.

Singleton pattern

I gotta admit this was a bit of a blunder at first. Coming from other backend frameworks; life-cycle is different in NodeJS. NodeJS features a persistent state application, opposed to other backend frameworks like Laravel which has request based life-cycle. I didn't knew beforehand so it became a issue at first. I wanted to make certain components and modules singleton to prevent redundant fetching and loading operations, to reduce redundancy. For modules such as Config and QuoteRepository this makes sense, because why would you load config or quotes multiple times throughout the lifecycle if they are not subject to change? After this discovery of persistent state life-cycle, I altered singleton logic to accommodate the requirements. It is not a crucial pattern to have but I have a habit of using it when it is possible for optimization purposes. Beware that if you're not proficient with singleton pattern or the life-cycle of the infrastructure you're using, it is very likely you'll run into errors and bugs.

Facade pattern

A classic design pattern. My quote fetching and selection criteria are quite vast in the application, there are many different aspects to consider and evaluate, ordering and selection to be made based on the contextual emotion matrix of the situation. To abstract this level of complexity from higher level modules, I applied facade pattern to simplify the acquisition of quotes by the strategy patterns. QuoteFacade is consumed by the strategy pattern implementations.

export class QuoteFacade{

    getQuote(actionContext:ActionContextDTO):Quote|undefined{

        //Case 1: if any other parameter along with slugs are provided: slugs and other filters will be applied separately and later be merged.
        //Case 2: if only slug param is provided, only will filter only by slugs.
        let quotes:QuoteCollection;

        if(actionContext.hasOnlyQuoteSlugs
        ){
            quotes=new QuoteCollection([]);
        }else{
            quotes=QuoteFacade.#quoteRepository.index();
        }

        if(actionContext.hasSentiment){
            //@ts-ignore
            quotes.filterBySentiment(actionContext.sentiment);
        }

        quotes.orderByCumulativeScoreDesc(actionContext.emotionMatrix,actionContext.tags);

        quotes.selectCandidates();

        if(actionContext.hasQuoteSlugs){//Damn this is ugly as hell
            let quotesBySlug=QuoteFacade.#quoteRepository.index().filterBySlugs(actionContext.quoteSlugs??[]);
            quotes.merge(quotesBySlug);
        }

        return quotes.shuffle().first();
    }

    getQuoteBySlug(slug:string):Quote|undefined{
        return QuoteFacade.#quoteRepository.find(slug);//Should we use the Repo's find or collection's find?
    }

}

Chain of Responsibility pattern

This one is really debatable and forced I'm aware. I wanted to implemented it because I've been seeking an opportunity to use it for a long time. Chain of responsibility is like a middleware structure, it passes or stops at the chains depending on assertions on each chain. My app configuration was dependent on both the BotConfig and RepositoryConfig of the user, I had to check and assert these whenever an action was due to happen, to simplify this I used chain-of-responsibility pattern.

const botConfigSubsHandler=new EventSubscriptionHandler(BotConfig.getInstance());

const repoConfigSubsHandler=new EventSubscriptionHandler(repoConfig);
botConfigSubsHandler.nextHandler=repoConfigSubsHandler;

if (!botConfigSubsHandler.handle(this.getEventName())){
   return;
}

Factory pattern

Even though we've abstracted the complexity by implementing Facade pattern for quotes, as QuoteFacade. This made strategy pattern implementations far simpler and cleaner, there wasn't anything in them that didn't belong there. But there was a small problem. Depending on the config, user may opt to see debug output or toggle emoji support. It is true we can easily obtain these settings from Config's but certain configs that are defined in the user's repository is bound to a event payload so we can fetch the repository config. This indicated a problem, QuoteFacade on it's own cannot do it because it doesn't have event payload context. And if we send it to the QuoteFacade by the strategies it would break SOLID principles and make testing so difficult. I resolved this by moving this requirement for config to a CommentFactory. CommentFactory takes a QuoteFacade instance and values for configs. This way the dependence between QuoteFacade, CommentFactory and Configs are broken, high achieved. Strategy pattern implementations were injected CommentFactory instances by the abstract strategy class and it was clean now.

const repositoryConfigPartial=await RepositoryConfig.readConfigFromRepository(this.ghContext as any as Context);
        const repoConfig=new RepositoryConfig(repositoryConfigPartial);

        const commentFactory=new CommentFactory(QuoteFacade.getInstance(),repoConfig.debug_mode,repoConfig.emojis);


const comment:Comment|null=await this.execute(commentFactory);//relaying to the child classes of the abstact strategy, each is responsible for the implementation of execute() method.

export class CommentFactory {

    #quoteFacade:QuoteFacade;
    #debugMode: boolean;
    #emojis: boolean;

    constructor(quoteFacade:QuoteFacade,debugMode: boolean, emojis: boolean) {
        this.#quoteFacade=quoteFacade;
        this.#debugMode = debugMode;
        this.#emojis = emojis;
    }

    get quoteFacade(): QuoteFacade {
        return this.#quoteFacade;
    }

    get debugMode(): boolean {
        return this.#debugMode;
    }

    get emojis(): boolean {
        return this.#emojis;
    }

    create(
        caseSlug: CaseSlugs.Types,
        actionContext: ActionContextDTO,
        replyToContext: ReplyContext | null = null,
        warnings: Array<string> = []
    ): Comment | null {
        const quote: Quote | undefined = this.quoteFacade.getQuote(actionContext);
        if (!quote) {
            return null;
        }
        return new Comment(
            quote,
            caseSlug,
            actionContext,
            this.debugMode,
            this.emojis,
            replyToContext,
            warnings
        );
    }
}

Stay tuned for part #2 where we will be covering the episode of unit and feature testing. Thank you for reading!

Ruin has come to your repository!

skywarth — Sun, 11 Aug 2024 22:17:38 +0000

Ever wished your GitHub repository could echo with the haunting, powerful narration of Darkest Dungeon's ancestor? Imagine your pull requests, issues, and comments narrated in that iconic voice, making every development decision feel like a step deeper into a dark, foreboding dungeon. Well, now you can!

Introducing Darkest-PR, GitHub app that transforms your repository into a thrilling adventure, filled with despair, hope, and everything in between. Whether you're looking to motivate your team, add a touch of humor, or simply make your workday more engaging, Darkest-PR is here to bring the ancestor's unique style to your development process.

Repository
GitHub Marketplace listing

What is Darkest-PR?

Darkest-PR is a GitHub bot that responds to repository events with contextual quotes from Darkest Dungeon. From pull request merges to issue assignments, Darkest-PR analyzes the situation and delivers a perfectly fitting quote. It’s like having the ancestor himself narrating the trials and triumphs of your development journey.

Examples of How Darkest-PR Works:

Someone is removed from PR assignment and the bot responds with:
- > "Send this one to journey elsewhere, for we have need of sterner stock."
PR is rejected (request change) and the bot responds with:
- > "Carelessness will find no clemency in this place!"
PR is closed without merge and the bot responds with:
- > "A setback, but not the end of things!"
PR is accepted and merged immediately and the bot responds with:
- > "A singular strike!"
Someone is assigned to an issue and the bot responds with:
- > "More arrive, foolishly seeking fortune and glory in this domain of the damned."

These quotes aren't just for show—they add a layer of narrative depth, making every decision and event feel weightier, as if your team is a party of adventurers facing the unknown.

Why Use Darkest-PR?

As developers, we often find ourselves dealing with the same routines such as: reviewing pull requests, closing issues, assigning tasks... Darkest-PR breaks this monotony by adding a unique, entertaining twist to these everyday tasks.

Key Features:

Contextual Quotes: Automatically delivers quotes based on the event context, bringing a touch of drama or humor to your repository.
Customizable: Tailor the bot's behavior to your needs with an optional configuration file.
Interactive: Mention the bot directly in comments to get a personalized quote, or use parameters to specify the type of quote you want.
Easy Installation: Get started in minutes, no complex setup required.

How to Get Started

Go to the Darkest-PR's GitHub App page
Click 'Install' button
Select the repositories you want to install the app
Confirm the permission and click 'Install'
Done! Enjoy.
So now whenever a use-case event occurs, or whenever you mention the app like @Darkest-PR it will respond to you!
Give it a try, submit a comment in any issue/PR in your repository mentioning the app. E.g: @Darkest-PR ancestor, do your thing.

Join the Journey

Darkest-PR is more than just a GitHub app—it’s an experience. Whether you’re a fan of Darkest Dungeon or simply looking for a way to make your development process more engaging, this app is for you.

Start your journey with Darkest-PR today. Let the ancestor guide your team through the darkest depths of development. Install it now, star the repository, and share it with your fellow developers. Let's make coding an epic tale worth narrating!

Built with love using Typescript and Probot framework.

Are you using OpenAI API? Then you need to be prepared!

skywarth — Fri, 05 Jul 2024 11:57:35 +0000

If you are dependent on OpenAI API, you should know that at some point in time it might go down, even for a short period. And in such cases you would like to know, act accordingly or maybe even run certain automations to mitigate the problem at hand. Those that do monitoring on their external dependencies know exactly what I'm talking about.

This article is for those:

Use OpenAI API in their apps, or have dependency on it directly/indirectly
Prometheus Server and Blackbox exporter users
Grafana, metrics and visualization enjoyers

Monitoring the status of APIs is crucial for maintaining the health and reliability of your applications. For those using OpenAI's API, the official status API always returns a 200 status code, even when the service is down. And naturally, this prevents you from probing this API via Prometheus Blackbox exporter.

This is where the OpenAI API Status Prober comes in handy. It acts as a proxy, translating the status into meaningful HTTP codes that integrate seamlessly with your Prometheus setup.

Key Features

Accurate Status Reporting: Converts OpenAI's status API responses into proper HTTP codes (200/500/3xx).
Easy Integration: Simplifies the process of integrating OpenAI API status monitoring into Prometheus.
Flexible Installation Options: Supports global, local, and direct usage methods.

Why Use OpenAI API Status Prober?

The primary motivation for using this tool is the limitation of the official OpenAI status API. By providing a proxy that returns appropriate HTTP status codes, the prober makes it possible to integrate OpenAI's status into Prometheus, enhancing your monitoring capabilities.

Usage

Installation

You can install and set up OpenAI API Status Prober using three methods:

1.Global Installation:

npm install -g pm2
npm install -g openai-api-status-prober
openai-api-status-prober start
pm2 startup
pm2 save

2.Local installation:

git clone https://github.com/skywarth/openai-api-status-prober.git
cd openai-api-status-prober
npm ci
node src/server.js

3.Direct Usage of Production Deployment:

You can use the deployment directly via https://openai-api-status-prober.onrender.com/open-ai-status-prober/simplified_status. However, it's recommended to self-host to avoid overloading the service.

Integrating into Prometheus Blackbox exporter

scrape_configs:
  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - http://127.0.0.1:9091/open-ai-status-prober/simplified_status
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

Then run systemctl restart prometheus

CLI Commands

Start Server: openai-api-status-prober start
Stop Server: openai-api-status-prober stop
Version: openai-api-status-prober -v
Env Path: openai-api-status-prober env-path

Repository: https://github.com/skywarth/openai-api-status-prober
Deployment: https://openai-api-status-prober.onrender.com/open-ai-status-prober/simplified_status

Apparently now I'm a trusted member!

skywarth — Wed, 03 Jul 2024 11:33:07 +0000

I just got an email that says now I'm a trusted member of the DEV.to, hooray!

What is trusted member?

After a brief research and reading the guide, it essentially grants the user the permission to moderate the content and posts on DEV.to

So basically you get these new permissions:

Access to mod center
Rank content quality
Rate post's experience/proficiency levels
Flag/report posts for spam or content that violates code of conduct

How do one get it?

The guide I've added below contains the answer to this but in essence, these are the crucial key points from it:

Be kind, always
Be helpful
Give back to the community: share your experiences, do open-source etc.

If you're inclined on learning more, please visit this page for all the details and questions you might have: Trusted Member Guide

Many thanks to DEV.to for granting this, I appreciate it. Happy to be part of this vibrant community.

Credits:
Cover splash art image is by John Cameron on Unsplash

Chaotic Schedule v1.1 released!

skywarth — Sun, 26 May 2024 20:36:00 +0000

Hello,

I've released a new version for Chaotic Schedule package. This new release introduces new random scheduling macro: hourlyMultipleAtRandom().

What is Chaotic Schedule?

Github, Packagist

Chaotic Schedule is a Laravel package which allows you to randomize command schedules, be it date or time. Want a sampler for taste of flavor, sure:

$schedule->command('foo:bar')

->weekly()

->randomDays(

    RandomDateScheduleBasis::WEEK,

    [Carbon::FRIDAY,Carbon::Tuesday,Carbon::Sunday],

    1,2

)

->atRandom('14:48','16:54');

Where can you use Chaotic Schedule?

Here's some use-cases which might be valid for you as well:

I have a command to send notifications to my clients. But I would like it to be sent at a random time between 14:00 and 17:00
I would like to send some gifts to users if they are active between my special event period which is every week Friday and Saturday between 00:00 and 04:20
My boss asked me to generate and send statistical reports regarding database activities every month, but only on Monday, Wednesday and Friday. And this report has to be delivered in the morning between 08:00 and 09:30 and I want it to look like I've personally generated and sent it personally. So random time and date is crucial to stage this.
I would like to send reminders to customers and I want it to look and feel human. So random run times and dates every week would help me a lot. Otherwise, if I send every week on Tuesday 11:00 they would know this is automated and ignore these.
There is a financial deficit, in order to detect the source of it I'll be running audit calculations. But these have to be random, otherwise they'll alter the records accordingly. I need to run audit calculations/assertions 3 times a day at random times.
I'm trying to detect certain anomalies in my data, and therefore it would help me a lot to run a command completely randomly but with a minimum of at least 100 times a year.

What's new?

hourlyMultipleAtRandom() can be used for scheduling your commands to run every hour on random minutes. Example use case: I want to run a command every hour, 1-5 times at random, on random minutes. E.g. run minutes:[5,11,32,44]

Runs every hour
Only designates random run time(s)
Runs multiple times per hour, according to $timesMin and $timesMax params
Doesn't designate any date on the schedule. So you may have to provide some date scheduling such as daily(), weekly(), mondays() etc.
Behaves exactly the same with ->hourlyAtRandom if the timesMin=1 and timesMax=1. (I mean duh)

Stir some chaos into your schedules: Chaotic Schedule package

skywarth — Sun, 31 Dec 2023 16:06:07 +0000

Hello everyone, I would like to share a fresh Laravel Package I've developed with you. This package uses pRNG and cryptography methods to randomize scheduled command run intervals.

Chaotic Schedule

https://github.com/skywarth/chaotic-schedule

Laravel package for randomizing command schedule intervals via pRNGs.

Packagist: https://packagist.org/packages/skywarth/chaotic-schedule

Installation

Consider the requirements
- PHP >=7.4 is required
Install the package via composer:

composer require skywarth/chaotic-schedule

(optional) Publish the config in order to customize it

 php artisan vendor:publish --provider "Skywarth\ChaoticSchedule\Providers\ChaoticScheduleServiceProvider" --tag="config"

Done. You may now use random time and date macros on schedules

Problem Definition

Ever wanted to run your scheduled commands on random times of the day, or on certain days of the week? Or you may need to send some notifications not on fixed date times, but rather on random intervals hence it feels more human. Then this is the package you're looking for.

This Laravel packages enables you to run commands on random intervals and periods while respecting the boundaries set exclusively by you.

Use Cases

I have a command to send notifications to my clients. But I would like it to be sent at a random time between 14:00 and 17:00
I would like to send some gifts to users if they are active between my special event period which is every week Friday and Saturday between 00:00 and 04:20
My boss asked me to generate and send statistical reports regarding database activities every month, but only on Monday, Wednesday and Friday. And this report has to be delivered in the morning between 08:00 and 09:30 and I want it to look like I've personally generated and sent it personally. So random time and date is crucial to stage this.
I would like to send reminders to customers and I want it to look and feel human. So random run times and dates every week would help me a lot. Otherwise, if I send every week on Tuesday 11:00 they would know this is automated and ignore these.
I'm trying to detect certain anomalies in my data, and therefore it would help me a lot to run a command completely randomly but with a minimum of at least 100 times a year.

Deploying Your Vite Apps to Github Pages is a Breeze with Vite Github Pages Deployer

skywarth — Sun, 18 Jun 2023 12:57:59 +0000

Hello hello!

If you're a developer using Vite for your Vue.js or React projects, and you're considering GitHub Pages for deploying your applications, then you've stumbled upon a gem. Today, I'm introducing you to a fresh open-source tool that is about to make your deployment process a piece of cake: Meet the Vite Github Pages Deployer!

What is Vite Github Pages Deployer?

Vite Github Pages Deployer is an innovative open-source tool designed to significantly streamline the deployment of your Vite applications to Github Pages.

Deploying via Github Actions feature is a beta feature, but provides an incredible new perspective on the deployment of your application!

Vite Github Pages Deployer harnesses the power of GitHub Actions and Artifacts, providing a seamless, customizable deployment process that takes away the stress of manual deployments.

Key features of Vite Github Pages Deployer include:

Zero manual/auto commits of the dist folder or pushing to a branch.
Seamless deployments to Github Pages leveraging actions and artifacts.
A high degree of customization with optional build paths. Clear error notifications and debug modes for hassle-free troubleshooting.

Usage Example

Here's a quick sneak peek into how effortlessly you can incorporate this into your workflow:

name: Vite Github Pages Deploy

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["master"]
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    environment:
      name: demo
      url: ${{ steps.deploy_to_pages.outputs.github_pages_url }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Vite Github Pages Deployer
        uses: skywarth/vite-github-pages-deployer@master
        id: deploy_to_pages

A Must-Have For Vue.js and React Projects

Whether you're whipping up a Vue.js application with Vite for a super speedy development experience, or a React project utilizing Vite's out-of-the-box React fast refresh and JSX support, Vite Github Pages Deployer will become your go-to deployment tool.

Where can it be utilized?

You need the Vite Github Pages Deployer if:

You're creating a Vite application with Vue.js or React and want an uncomplicated, efficient deployment process to Github Pages.
You're seeking an automated, reliable solution to save you from the monotony of manual deployments.
You're developing open-source projects and would like to showcase it free-of-charge.

Give it a go!

Embark on a simplified journey with Vite Github Pages Deployer and discover how it can revolutionize your deployment process, transforming it into an effortless task. Check out the demo project to witness it in action.

As always, contributions of any kind is welcome. Reviews, suggestions, PRs and issues are appreciated.

And lastly, if you find Vite Github Pages Deployer beneficial, show your support by giving a ⭐ to the repository.

Enjoy!

Simulating wolf pack in JS with Fenrir

skywarth — Fri, 28 Jun 2019 11:34:17 +0000

https://github.com/skywarth/Fenrir-wolfpack-simulator

Fenrir is an assistant to prognosticate the future of a wolfpack using vanilla Javascript and data structures.
Simulation and prediction includes:

Changes in the environment
Health and status of individual wolves
Disease conditions of each wolf
Weather events and effects
Alpha rankings in the pack
Mortality status of pack members
Wild card encounters (triggered by scout event)
Meat distribution
Regular events
Irregular events