In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in comments, as opposed to just using issues as a task list. Epic

Backend

• Refactor the backend endpoint to verify the signature of a JWT to ensure authenticity. Note – this was a great learning experience in better understanding how async and await work in JS. This issue took me way too long to resolve. Squash Commit

• Further briefly modify the endpoint to pull specific custom data out of the generated JWT from Keycloak. Commit

Frontend

• Configure Docker compose files and Git submodules to containerize all three repositories into the fake frontend to test the whole flow. Commit

• Completely facelift/refactor/rework/reimplement the fake frontend to use Vue as a build framework to test our implementation in the same context as it will be used in production. Configure dependency and instantiation of Keycloak in the JS to handle redirect and access token storage and usage. Commits: 1 , 2

Something that worked particularly well this sprint was our focus on increased communication. We refactored our working agreement to address some of our shortcomings in communication and accountability, and I felt like this sprint was better for us around the board. We had a bit more direction this sprint, and we accomplished our goal exactly as we laid it out, barring 2 lines of code that we have to add that are just blocked right now.

That said, – at risk of contradicting myself – I feel like something that did not work as well, and that we can continue to improve, is also our communication. Though it was better this sprint, it still definitely felt at times like we were not a team, and instead like we each had our tasks that we would connect on once or twice a week in class meetings. Maybe this is fine, and to be honest it worked okay for the most part, but I feel like in an ideal world for me, I would have us all being very proactive and communicative about our issues, though I don’t know if this is a fair thing to aim for our team to improve, or if maybe I should reevaluate my expectations.

Something I could improve is my focus on defining roles and responsibilities for the general team dynamic, not just for issues. I felt like I focused on accountability for issues on GitLab, for example, but I also feel like I informally assumed the role of Scrum Master / Sprint Lead for this sprint, though we never really defined or said that. It seemed to work fine for us, but it is something I think I could have specified better, instead of just sort of assuming a leadership role.

The pattern I have chosen for this sprint is The Deep End. This is because one of the issues I spent the most time on during this sprint was implementing JWT signature verification. This should not have been a difficult issue, but I really have never worked with functions in js specifically, and for some reason I was caught in a loop of bad syntax and usage of things like const, async, and await. I had no idea what I was doing, and was so lost as to why my code was not working. It took a lot of reading and being lost for a while before finally realizing my error was not the libraries I was using, but just a lack of understanding regarding js. 

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

After finishing our second sprint I believe it went very well. Our team did a great job of communicating, time management and ensuring everyone’s ideas were heard. We also made sure to ask each other questions if we were stuck on an issue as well as ask anyone if they needed any help with their issue if they were having any problems. I believe the only problem we had was reviewing the issues, we either got a little sidetracked or were waiting on a response to a question we had about the issue so it kind of prevented the reviewer from checking on it. As a group of 5, we needed a weight total of 30, we managed to complete all of our issues. Since the last sprint, I believe we made a lot of progress as a team and managed to get through this sprint without a lot of issues.

As a team, I believe we made a lot of progress in this sprint and didn’t have a lot of issues to work on. We made sure to communicate with each other about how everyone’s progress was going on with their issue and if they needed any help with anything. The reason why we managed to get through this sprint is because of our communication and teamwork. As a team an improvement that we can make is our reviewing, we did have a couple of issues left in the needs review column that just needed to be checked but we kind of delayed that. I believe that was our only problem this sprint since for most of the issues we worked as a group and managed to get it done in one meeting. If we just made sure to stay on top of any work that needs review I feel like our sprint would’ve been done sooner than later.

As an Individual I believe I made a lot of improvements since the last sprint. I made sure that the work was even spread out between me and the team. The issues I worked on were Get the InventorySystem General test and build working and Verifying GuestInfosystem/Documentation. I made sure that the guestinfo system documentation had the right extensions, linters and that the pipelines were working. The only problem I ended up having was with the inventory system general test and build working. I just ended up asking Professor Wurst what I should do with them since by looking at other repos the general didn’t have a test or build so I just ended up disabling those pipelines and everything ran smoothly. Next sprint I plan on working on my issues and making sure that nothing sits in needs review so my team members don’t have to do more work than they need to and make sure that I’m contributing as well. I also plan on making sure to get any questions I have asked as soon as possible so that the issue can be solved sooner rather than later. 

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

As we wrap up our second sprint, it’s time to pause, reflect, and glean insights from the journey we’ve undertaken together. Sprint 2 has been a period of significant learning, characterized by both triumphs and obstacles that have shaped our team dynamics and individual growth. In this retrospective, we’ll delve into the challenges we faced, the lessons we learned, and the strategies we’ll implement moving forward.

One of the pivotal challenges we encountered during this sprint was the coding of a UI component. Initially perceived as a straightforward task, it quickly evolved into a complex endeavor due to unforeseen changes in the source. These alterations necessitated extensive adjustments to our initial plans, leading to delays and frustration. However, amidst the challenges, we discovered an opportunity for growth. By grappling with the intricacies of the component and adapting to evolving requirements, we honed our problem-solving skills and gained a deeper understanding of UI development. This experience underscored the importance of flexibility and adaptability in the face of unforeseen circumstances, emphasizing the need to approach tasks with an open mind and a willingness to iterate and refine our approach.

Another significant aspect that influenced our sprint was the weight of certain child issues. What initially appeared as minor tasks turned out to have a more substantial impact on our workflow than anticipated. This discrepancy highlighted the importance of thorough planning and assessment when breaking down tasks and allocating resources. Moving forward, we recognize the need for a more nuanced approach to issue prioritization, ensuring that each task receives the appropriate level of attention and resources commensurate with its importance. By fostering a culture of careful planning and strategic resource allocation, we aim to mitigate the risk of unexpected bottlenecks and delays in future sprints.

Despite the challenges encountered, sprint 2 has been instrumental in fostering our team’s growth and development. We’ve had the opportunity to enhance our problem-solving skills, adapt to changing circumstances, and refine our communication and collaboration strategies. Effective communication emerged as a cornerstone of our approach, enabling us to navigate challenges and coordinate efforts seamlessly. Whether through online discussions or face-to-face meetings, we remained committed to fostering open dialogue and transparent communication channels, ensuring that everyone remained aligned and informed throughout the sprint.

Looking ahead, we recognize the importance of carrying forward the lessons learned from sprint 2. We are committed to prioritizing effective communication, proactive problem-solving, and meticulous planning to ensure the success of future endeavors. Additionally, we plan to leverage our experiences from this sprint to inform our approach in subsequent iterations. By documenting our challenges, solutions, and key takeaways in a “lessons learned” repository, we aim to create a knowledge base that will serve as a valuable resource for future sprints, enabling us to anticipate and mitigate potential obstacles more effectively.

In conclusion, sprint 2 has been a journey of growth, resilience, and collaboration. While we encountered our fair share of challenges along the way, each obstacle served as an opportunity for learning and development. Armed with newfound insights and a renewed sense of determination, we look forward to tackling the challenges that lie ahead and achieving our goals as a team. With a shared commitment to continuous improvement and a supportive team environment, we are confident in our ability to overcome any obstacle and emerge stronger than before.

Links to issues covered:

Review GUI mockup
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/45

Coding new UI and fixing gitpod implementation
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/43

From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.

What Worked Well:

Sprint #2 was another productive learning experience for our team. We were able to continue building upon the momentum gained from Sprint #1 and were able to achieve commendable progress. In this sprint, we were tasked with completing eight different issues to reach a total issue weight of 30. We crushed this number, completing all eight of our issues on our issue board before the end of the sprint. Something worth noting was our familiarity with the project, what tools we needed, and the process. When comparing last sprint to this one, we found ourselves navigating through GitLab and GitPod more efficiently without any major issues. This resulted in a much smoother workflow. Additionally, I thought that our communication throughout the Sprint remained a cornerstone of our success. We stood up to date with scheduled meetings through Discord and in-person, allowing us to touch on some points, any updates, problems, discussions, and allowed for collaborative problem-solving. This consistent communication fostered a sense of cohesion within the team and ensured that every team member stayed aligned towards completing our tasks. I also found our workflow to be great. We completed some issues together and some individually, but as we finished one thing no one was hesitant to pick up another issue, help someone out, or review work. In regards to what didn’t work well, I don’t have much. Sprint #1 was a learning process for the entire team and once we understood everything, how to time manage our work, and how everything functions in the system, we brought what we learned into Sprint #2. We were able to complete tasks in a very timely manner while also knowing exactly what’s happening in the system and how to correct any issues.

Improvements As A Team:

We made some drastic improvements from the previous sprint in regards to how we took on work, the time we worked on it, our review process, and much more. Although I really liked the progress our team made throughout this sprint I believe one possible area for improvement could potentially be commenting or adding notes for work being completed. As stated, some tasks we completed individually. With this being said, when having other individuals of the team review work, it can be a little challenging to actually see what was changed, added, or the thought process behind someone’s work. By adding some comments directly to issues or connected to merge requests, it allows for both reviewers and anyone going through the work to easily understand what was completed, added, or needs to still be done. A simple message such as, fixed linter errors or solved merge conflicts can go a long way.

Improvements As An Individual:

During Sprint #2, I was able to complete one issue individually and two issues with my team. My first issue was Get Inventory Backend Test Working in InventoryBackend. In Sprint #1, we had some issues with the Inventory System test pipeline. I wanted to really get that testing pipeline to work to continue progressing the project forward. This issue involved me creating a test-runner file, along with an automated_testing_docker-compose.yaml file to integrate into the project. I also communicated with other groups for what they were completing to then integrate our work together and have the testing pipeline run and pass. My second and third issues were completed with my team. This being Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the GuestInfoBackend, and Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the GuestInfoAPI. These issues involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes and correct the issues. In regards to improvements as an individual, I’d like to see myself become more of a team player for our last sprint. Sometimes I tend to get so focused on fixing and completing one issue that I forget to check in with the needs of the rest of the team. For me, this could be jumping in to help someone that’s stuck on a specific issue, reviewing the team’s work and providing feedback, and even voicing my thoughts, interests, or opinions more to my team. By doing so, I believe it’ll help me grow as an individual and a teammate, and help me tremendously with my professional career.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

This sprint went pretty well. There were a few more issues than with the prior sprint; however, those issues were out of our control for the most part. The first issue I worked on this sprint was issue 15 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/15). This issue was very easy for me to complete; I only had to make minor corrections. The next issue I worked on for the first week was issue 46 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/46). This issue was more challenging to complete, and I had to continue to work on it during the following week.

In trying to complete this issue, I had to revert the changes that I had made to issue 46 during the first meeting in order to make progress in completing this issue. Sadly, I was still unable to complete this issue during the second meeting period, but I was confident in the progress that I was making. I messaged Dr. Wurst at the time to see if he could help me solve the issue I was facing. During the third meeting, I found that I was unable to make more progress on issue 46, so I decided to begin working on issue 151 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/151 ). During the third meeting, I made some progress on issue 151, but the issue still needed more work to be done before it could be considered complete.

The fourth meeting went better than the prior two meetings for me. I was able to complete issue 151 and begin working on issue 72 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/72). I started working on the first child element in this issue, which was researching how to implement nodemon into the inventory backend. I found one article detailing the implementation of nodemon and the documentation for nodemon, which I made a comment on under the child element for this issue.

Before the fifth meeting, Dr. Wurst released a fix for the problems that I was having with issue 46. After checking to make sure that nothing else needed to be fixed with the issue, I moved on to issue 37 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/37). I was able to finish most of issue 37 during the fifth meeting. However, I still needed to complete a little more before being able to push it to the next stage of development.

The sixth meeting was going smoothly at first; while linting issue 37, I ran into a problem with the pipeline. I could not correct this issue independently, so I contacted Dr. Wurst for help. In the meantime, I continued to work on linting through the git pod instead of the git lab pipeline. I finished the sixth meeting by completing the linting as best as I could without being able to test the pipeline, so I had to wait for the next meeting to be able to continue with this issue.

During the seventh meeting, with the help of Dr. Wurst and Mike, I was able to overcome the issue I had from the prior meeting. After that, I was able to use the pipeline to finish linting, and I was able to get most of it done before the end of the meeting. However, there was a little more left to be done before the issue could be completed.

During the eighth meeting, I dedicated my time to reopening issues that were closed by mistake so we could accurately gauge how much we could complete during this sprint. I found a way to access which issues a user had closed, which made this process much easier for our group.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

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’

Added Mocha test framework and Chai assertion library as developer dependencies to ‘InventoryBackend’

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.