When I was working on travis.yml, file name, I was having a lot of difficulties because I have never worked with Travis before. The good this was Travis had pretty decent documentation so I could set up the Redis server and homebrew as well. Once that was done I tasted my code and to do that I had to make a pull request because when I tried to test it locally it didn't test the travis.yml file since I didn't have my system set up for Travis. So when I looked into how to set it up locally I found a StackOverflow entry explaining all the sets. So I followed them and found out my mac is full, I don't have enough space to set up the docker and Travis so I started deleting unnecessary files and apps that I didn't need and used any more. That gave me four gigabytes of space, not enough, but just enough for me to set Travis and Docker up locally. So I tried setting it up and failed miserably. So I researched a bit more and I started noticing some issues with the performance of my mac because there was not enough space. Then I deleted docker and uninstalled Travis. Following all that I decided to set in a pull request and let the GitHub Travis test my code. Great I got that started and every time I git added, committed and pushed my change to GitHub, it ran Travis. Now I started reading up on Travis syntax, how to configure on travis.yml, looked at other example code on Github for travis.yml and looked on StackOverflow. From all that searching I learned how to add addons for mac, essentially setting up the VM for the Redis server. Then how to run the Redis server on mac with an if statement so when the test runs for windows it doesn't run the server start command that mac would run. Another thing I found out was that services are not supported in mac but are in Linux so when the yml file had the syntax "service: redis-server" it started the server for Linux and that's how I came to find out the server needed to be started manually. After I started them manually with the following commands: "redis-server /usr/local/etc/redis.conf" for mac and "server.exe" for windows. When I did that during the Travis test the servers would start and be in a state to accept a connection but never received the connection. That puzzled me so I asked for help and I found out it would be started during the test so I just needed to install them or so I thought. Following what I thought I understood I removed the server start commands and ran the Travis test again. This time it came out as there is a problem with the asynchronous test function so I thought great I think I set up the system properly because I didn't work on test functions. But turned out during the test the Redis server had not set a default URL. So that makes all the following tests fail. In setting up Travis ci for windows I had one major problem but all the other steps were the same, setting OS as windows, installing Redis for windows and starting it. The major problem was the prettier format. For windows EOL, end of the line, the format was CRLF but Travis needed just LF like how mac and Linux have their EOL ad LF. I had no idea how to set this up. So I searched a bit and found out that this can be turned on and off in git config global core.autocrlf. Then I inserted that line as a "before install" command in and ran Travis. It did nothing. So I searched a bit more and found a code block on StackOverflow to fix the exact same problem I was having. So I took that code block and used it in my yml file and I commented the link right before the code block. Finally, I pushed my code and it got reviewed and merged. Then my prof sets up a new issue to fix why the Travi ci test was failing for all other commits. This scared me a little because did I break the whole system. Turned out I did with my merge. Then he recorded the whole file to fix the fix I should have fixed. Later I found out that the problem was caused because the Redis server was not starting since it didn't a default URL.
This was a really big mistake I caused and I realized it after. The lesson learned is never messed with setting up the configuration of a system ever again!!!! Nope, I am just joking but what I actually learned was 1.) if a test fails before merging on GitHub you are doing something wrong, take a second, third or even a fourth look and find out why it's not working properly. If you still can't ask for more help and clarification and do a deeper dive into searching. 2.) never push code that fails CI because it will cause huge problems for other developers who are depending on it. 3.) if part of the tests or CI is failing, move that bit to a new pull request against landing everything at once.
For the external after my confidence in myself failed, I tried to do something simple. So I found a Microsoft project on GitHub called fast-dna which is about "an unopinionated system of components, development tools, and utilities used à la carte or as a suite to build enterprise-grade websites and applications"(fast-dna, line-1). This project is all typescript. Honestly, I choose this project because there is a simple issue I can work on here when the scroll bar should show a number when changed and it was a good way to refresh my memory of typescript. But the second objective failed I couldn't remember anything I learned of typescript. So on the same project, I found another issue of moving a file from once component package to another component. I did that and sent in a pull request but it failed their circle ci test. So now I gotta go back and look at where I am failing. So learning from my previous mistake I have not merged this code yet but I will send in for another review once I solve this problem.
This release, 3, has been a great learning experience for me in why testing is important and not merging anything that doesn't pass the test. Even with the Microsoft project, I failed the build dependencies so I think it might be due with not changing the path of the file import in some component but I will look at it again. This is one lesson I will never forget moving forward.