I felt like I went into this sprint confident that the tasks we planned to approach at the start would go well based off of what we learned from the first sprint. To start the sprint off our team met with Team 1 on Discord. We discussed what we learned about frontend testing, including vues and how to build a frontend in gitpod. This is where that confidence was immediately squashed when I began to realize the depth involved with setting up all the linters for a frontend and linting all of the files.
During the entirety of the sprint I was stuck tackling this one issue; setting up linters in GuestInfoFrontend. This issue was originally weighed by the team as a 2 based on everyone linting their repositories in the previous sprint. Come to find out, linting a fully built front end can take some time.
The initial Issue I ran into was understanding how to enable each linter in the pipeline. The main reason I failed to properly lint the GuestInfoFrontend in the previous sprint was that I never enabled the linters. To make sure I had every linter I needed I read the documentation for each linter and picked ones that linted any file that existed in the frontend. The linters I used were alexjs, cspell, hadolint, lint-package-json, markdown-link-check, markdownlint-cli2, shellcheck, spectral, eslint, htmlhint, and style lint.
Eslint, htmlhint and style lint didn’t end up working with the pipeline and were removed. Issues were made under each of their respective repositories detailing the error message. Eslint still worked locally, so linting was still able to be done to the files.
As for the other linters, I was able to learn a decent amount about configuring rules for each one of them. This includes understanding what to name the config file, how to format the rules, and what rules exist. Unfortunately It turns out that the rules I created are only checked locally, which makes sense. So my files would still fail the pipeline without the proper lint ignore comments. This was something I tried to avoid at all cost, as it just feels like a cheap and easy fix. That being said I look forward to maybe taking my proposed rules further up the pipeline.
What Worked Well:
The team’s communication was again the best part of the sprint. There were times where one of us would get stuck or fall behind. Having them communicate what is going on allows the rest of the team to be aware of the situation and adjust accordingly.
What Didn’t Work Well:
With me being stuck on one issue the whole time, I felt guilty as my team was responsible for the entire rest of the board. Because my one issue encapsulated other smaller issues, none of the progress on each of the smaller issues could be reflected on the issue board.
Team Improvements:
As a team we have noticed that there have been issues that essentially have child issues. These child issues get overlooked when we are weighing the issues before the start of the sprint. In my case where I was stuck on one issue, if it was originally built as the 9 separate issues I could have been easily divided up amongst the team. At the very least it would have reflected progress being made on the issue board.
Another improvement we can make is our documentation. Although we do a great job relaying information internally, it is important to remember that we are not the only team that will see these issues. Having comments explaining why we did what we did or sources for where we got our information can assist others who look at the issue.
Personal Improvements:
At some point during the sprint I installed at least one package in the wrong directory. There were times this was done because I didn’t know any better, and others by accident because I just forgot to move the working directory. This created many issues and a mess of unnecessary files. Moving forward I need to double check the working directory before installing. Not only this, but having better commits could help revert back to before the installation. Overall this has given me a better appreciation for the power of git commits and its record keeping.
Issues:
Meet with Team 1 to discuss frontend testing:
Set up linters and lint the GuestInfoFrontend repository:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/95
CS Learning 