ssg-cli-tool VS SauSaGe

There was another repo I tried to add test for, and it uses the same setup as mine. It uses JavaScript and achieve CI via GitHub Action, except that it also run test for version 14.x and 16.x of Node.js. Given both repo use Jest for testing, It's pretty easy to write test for the repo. I needed to spend time to understand the code and then run test coverage and see the existing tests to see what's needed to be done.

Automated testing commit: https://github.com/alexsam29/ssg-cli-tool/commit/dff551f7690bf7caaa3db6902b934145df401853

For lab 7 in my open-source course (DPS909), we were asked to implement static analysis tools into our static site generator (SSG).

For lab 6 in my open-source course (DPS909) we were asked to explore features of another popular static site generator (SSG) called Docusaurus. After creating our own demo website using Docusaurus, we were asked to choose one feature that we would like into our own SSG project.

GitHub Repo: https://github.com/alexsam29/ssg-cli-tool Refactoring commit: https://github.com/alexsam29/ssg-cli-tool/commit/cb9bb6e4278680df99c9202ca17288703cebe885

I had an issue that was created on my repo that wanted to add similar feature.

This week I worked with Alex to add a new feature to our SSGs. This new feature was the ability to use a JSON config file to pass in options instead of typing in the options manually in the command line. I worked on Alex's repo.

I continued working on my Static Site Generator and decided to add two more features. I created issues for each feature that I wanted to add.

My Conbtirbution I openned an issue and made a corresponding pull request for an open source Static Site Generator project by Alexander Samaniego(alexsam29). The goal was to add support for parsing Markdown files into HTML files, while also supporting italicization for those. Of course, I needed to update the README.md to reflect the changes.

After completing release 0.1 of my static site generator and having that code reviewed by another person in lab 1. It was time to start contributing to other projects and to learn how to create PRs. In addition, it was a chance to put our code reviewing experience from lab 1 to work by reviewing other people's PRs and code changes on our own repo.

The following is my PR to his repo to test his CI: pull18

This week, I set up CI for my SSG project. This involves creating a GitHub workflow for GitHub Actions to use. I started with one of the starter workflows. Specifically I used the msbuild one. To give a brief explanation of what adding this file will do, upon pushing changes or, a pull request it will create an environment that can be used to run my program. This is helpful if any tests, or other checks need to be made to verify that everything is in working order after changes to the project have been made.

This week, I added a testing module to my SSG. Since my SSG was created using C++, I used Catch2 as my testing framework. I chose Catch2 as my testing framework since it seemed to be the most popular among C++ developers, and it was all contained within a single header file.

The experience in rebasing my code went very smoothly. I was surprised how easy it was to squash all my multiple commits into a single commit. The process was straightforward with a bit of guidance from the on-screen instructions as well as the instructions of the lab. This was the commit I made.

In this lab, I added to my SSG program (SauSaGe) in order to demonstrate the process of working with and merging parallel branches in a project.

This week I've been working on adding some features to SauSaGe - Static Site Generator (SSG) built with C++.

Issue #1: Multiple new lines add empty unclosed 'p' tags.

1. This was an issue that I knew was present in my code but I had yet to find a solution for. At the time of writing, it has been solved using an else if condition instead of an else. 2. This issue I had not thought of, since in many cases command-line applications can be executed from any location. However, without changing PATH variables (which may be too advanced for some users), this issue will remain present. So, I will have to do with simply placing a step in the instructions to execute the application directly through the command-line. 3. This issue was found to be intentional. It remains in place because it prevents .html files to be created out of sub-directory files in the initially inputted directory. 4. This issue was a little more difficult to solve without increasing the coupling of my Text module and main function. I had to resort to placing the open and closing HTML tags as a constant variable in the Text module's header file in order to reduce code repetition. 5. This issue was the similar to issue #5 that I posted on my partner's repo. Since I used a different programming language to code my application than my partner, I had to find my own solution to this issue. The fix itself was straightforward using the filesystem standard library's functions.

I just finished making my SauSaGe (Static Site Generator), excuse my idea of a "creative name".