Throughout Sprint 2, which began at the start of March and was divided by our week of Spring Break, our team tried to spread our work out across several of the repositories in Thea’s Pantry instead of focusing on just one. Our tasks in each repository were centered around making sure the linter extensions were configured correctly in the Gitpod workspace, and that these same extensions would be included in the Gitlab pipeline whenever a new push is made to the repository.
These tasks were more difficult in some repositories than others. Repositories that had received more attention in the recent past required little work or reconfiguration in order to run the ‘lint.sh’ shell script and have no errors reported in the Gitpod terminal. Most of the issues that I encountered were with the formatting of developer documents. These files were reviewed by the ‘markdownlint-cli2’ linter, which has a set of rules that it expects the markdown files written by the developer to follow. These rules include a limit on the character length of each line and a restriction on trailing spaces, which I found were the two most common issues I needed to address in the developer documents.
One prominent difficulty I had in configuring each linter was learning where in the repository each extension looked for exceptions to their built-in rules. The ‘markdownlint-cli2’ extension had its own file in the root of the directory, as did a few others including ‘alexJS’. Other linter extensions had more obscure locations; the frustratingly similarly named ‘markdown-link-check’ needed additional arguments to be added to its invocation within the ‘lint.sh’ script, and not written in a distinct file in the repository like most other linters. Each member of our group discovered the necessity of modifying the linting shell script after running our initial ‘npm install’ commands. This command creates a hidden directory in the root of our repository called ‘node_modules’, which contains files related to the extensions we have installed as project dependencies. However, if we attempted to run the ‘lint.sh’ script without explicitly ignoring the ‘node_modules’ directory, some of our linters, the ‘markdown-link-check’ especially, would run for a prohibitively long time reviewing files in the ‘node_modules’ directory. Since the ‘node_modules’ directory contains files written by developers outside of the Thea’s Pantry project, it isn’t our responsibility to lint these files.
One special responsibility that I had for this sprint was to research the Mocha testing framework and Chai assertion library for later use in Thea’s Pantry. The ‘GuestInfoBackend’ repository already had a functioning test framework, and I used that as a model for adding Mocha and Chai as dependencies to the ‘InventoryBackend’ repository. My first task in the ‘InventoryBackend’ repository was to create a ‘testing/test-runner’ directory which would hold the package files and unit tests utilized by Mocha and Chai. Then, I was able to install Mocha and Chai in this subdirectory through the npm utility. Once I had installed all the files, I needed to modify the ‘test.sh’ shell script to call the Mocha framework. I got caught in the weeds at one point because I thought that the ‘docker-compose-test-runner.yaml’ file would create the Dockerfile, and I didn’t know whether this Dockerfile was supposed to be manually created or edited by the developer. I resolved this issue with the help of Professor Wurst by copying the Dockerfile present in ‘GuestInfoBackend’ and modifying it to meet the needs of ‘InventoryBackend’.
There were a few more steps to go before successfully integrating Mocha and Chai into ‘InventoryBackend’, including adding an ‘entrypoint.sh’ into the ‘test-runner’ subdirectory, as well as installing Yarn as an additional dependency. After my ‘lint.sh’ was returning no errors, I had to add the ‘test’ stage to the Gitlab pipeline. In the previous sprint, I thought that adding pipeline components was something our group would need to ask permission for, and only realized near the end that we actually had that capability as developers through the ‘.gitlab-cli.yaml’ file. Armed with that knowledge in this sprint, I realized that all I needed to do to enable the ‘test’ stage in the ‘InventoryBackend’ pipeline, was to remove the ‘test’ argument from the ‘disabled stages’ field.
One thing that I think our group could improve on is our review process before pushing our work to the main branch. What we’ll usually do when one of us is ready to create a merge request for our branch, is pick another one of our group members that we haven’t asked to review our previous merge request and have them approve the changes and remove the ‘draft’ marking from the merge request. What I looked for as a reviewer was whether all the pipeline stages passed, primarily. In the future, if we are working on configuring linters again, I think it would be best to have an example of working linter configurations to compare our changes against. This way, I think we would spend less time untangling the proverbial knots that the linters are catching on, and we would also avoid the possibility of introducing breaking changes to the repository.
Work:
Reviewed Mocha and Chai documentation for integration into ‘InventoryBackend’ repository
Configuring linters and Gitlab pipeline in ‘InventoryIntegration’
Add Yarn as developer dependency to ‘InventoryBackend’, in the process of integrating Mocha and Chai
Configuring linters and Gitlab pipeline in ‘ReportingBackend’
From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.