I set out to add further development and contribution tools to my ez-txt2html converter. Specifically, I wanted to introduce an initial Continuous Integration workflow. For this, I used the “Python Application” workflow template in Github Actions to create a CI testing workflow that builds a Py v3.12 environments, builds the project dependencies, runs Flake8 linting and Black formatting and then subsequently runs PyTest using the test suites I’ve written previously.

What was generated after confirming the details by which to build the workflow was a YAML file that defined:

• what actions should trigger the workflow to run. In this case any push or PR to the main branch.
• what OS the build environment should run on, defined as Ubuntu for this build.
• what steps to execute in the build and workflow, including:
  • run checkout v3 module.
  • python version to be installed.
  • process to install project dependencies.
  • run linting.
  • and run tests, in this case using PyTest.

Setting up this basic CI workflow was a breeze and was a process I feel I could have utilized many times in past projects to streamline additions to projects. It is fair to say my workflow used strictly defaults provided by the template, so there remains a great deal of exploration to be done, in terms of utilizing the full capabilities of GitHub Actions. I am very excited to expand my understanding how to harness the potential of CD and CI for greater efficiency and productivity. Rest assured I will post some updates as I explore further.

Over the last few weeks I have spent some time contributing testing functionality to a number of projects, which was met with with drastically different results. In an upcoming post, I will deep dive into exploration of setting up a Jest test environment and writing front-end testing for a JavaScript web application that I have contributed to in the past. I faced many challenges in this process, which I look forward to sharing soon.

On the other end of the frustration spectrum, I was able to look at what one of my peers has been doing with a similar static site generator (text to html converter) application. This is a TypeScript project I have also contributed some code to in the past, where I discussed some of the initial challenges of configuring the project environment, which required me to setup Windows Subsytem for Linux. This project utilized Bun as an alternative to node.js to build and run the application. While there was an initial implementation curve that took a lot of work to get through, however my current task of contributing some additional tests to the existing test suites, was seamless utilizing the tools provided by Bun. The simplicity and ease of Bun’s built-in test environment really made the process effortless. Now I was just adding to an exiting test setup, so I can’t speak on the process to get Bun configured, but writing and running test with the provided tools was very easy, particularly in comparison to configuring the PyTest environment for my project.

As I mentioned, I have a great deal of exploration to do in terms of code coverage for my projects and fully utilizing GitHub Actions, but what I have learned so far really feels like a major step towards understanding the full spectrum of developing and supporting open-source projects.