Add CI workflow to repo

Arrange your GitHub Actions CI Workflow

1. Create a .github/workflows folders within the root of repo
2. Create a workflow YAML file, ci.yml, for the CI job as under

title: ci

on:
  pull_request:
    branches:
      - fundamental
  push:
    branches:
      - fundamental

jobs:
  lint:
    title: ESLint
    runs-on: ubuntu-newest
    steps:
      - title: Examine out code
        makes use of: actions/checkout@v3

      - title: Setup node
        makes use of: actions/setup-node@v3
        with:
          node-model: '20'
          cache: 'npm'

      - title: Set up node dependencies
        run: npm ci

      - title: Run ESLint
        run: npm run lint

  unit-exams:
    title: Unit Checks
    runs-on: ubuntu-newest
    steps:
      - title: Examine out code
        makes use of: actions/checkout@v3

      - title: Setup node
        makes use of: actions/setup-node@v3
        with:
          node-model: '20'
          cache: 'npm'

      - title: Set up node dependencies and run Checks
        run: npm set up-ci-take a look at

NOTE: This workflow runs linters adopted by automated unit exams. It will likely be triggered each time a pull request is made or somebody pushes commits to the principle department.

How did your companion’s repo and testing setup differ from yours?
Initially, my companion makes use of pytest for Python, so the testing setup was utterly totally different from mine. One factor I seen was the absence of a config file for the exams. I needed to replace my .eslintrc.cjs to tell ESLint that my repo makes use of Jest. Moreover, there was no setup so as to add npm scripts to package deal.json to run the exams, so long as pytest is put in. With out including something, a easy pytest does the identical trick as npm run take a look at. I discover the testing setup for Python a lot easier and simpler than for TypeScript.

What was it like writing exams for a challenge you did not create?
Whereas writing unit exams, there have been sure factors the place I wanted to revisit the goal code that I wished to check and make adjustments to the unique code. Nevertheless, I used to be not sure if I used to be allowed to take action, contemplating the unique code was not written by me. As an illustration, exit() was used when a FileNotFoundError occurred within the unique code.

    attempt:
        with open(input_file, "r") as file:
            text_lines = file.readlines()
    besides FileNotFoundError:
        print(f"Error: {input_file} not discovered.")
        exit()

The difficulty was that this system didn’t exit instantly once I tried to check this code. After some analysis, I found that utilizing increase as an alternative would obtain the specified fast program exit. This manner, I can take a look at the code to make sure that this system raises an exception, as proven under.

    @patch("builtins.print")
    def test_process_non_exist_text_file(self, mock_print):
        with self.assertRaises(FileNotFoundError):
            process_text_file(
                "examples/test-folder/invalid.txt", "examples/test-folder-output"
            )

        mock_print.assert_called_once_with(
            "Error: examples/test-folder/invalid.txt not discovered."
        )

End result

Extra particulars in GitHub: pr

What do you consider CI now that you have set it up for your self?
There have been many instances once I pushed commits to the principle department earlier than checking for linter errors, which can break this system. I spotted that organising the CI workflow makes a developer’s life a lot simpler, because it reduces the variety of issues to fret about by stopping minor linter bugs and saving a big period of time.

Extra particulars in GitHub: pr