Working on installer.to with SCoRe Lab for GSoC 2020: Week 2

My previous Medium article got published under SCoRe as https://medium.com/scorelab/working-on-installer-to-with-score-lab-for-gsoc-2020-a6c919a80ab9!

I continued working on ShellSpec as it looks promising. We did one improvement, like, instead cURLing the script from internet, I’m now using the installer.shs inside the repo itself because they are both identical and the idea of the tests is to check if the installer.sh is really working instead of it is downloadable. This will save us some more time when running tests.

We came into another issue where some installer scripts are interactive and we have to test them by interacting with them also. I searched for a solution and all lead to one tool! Expect! A Linux tool where we can tell it how to interact with another interactive application and get our needs done. We can scrip the choreography in a exp file and when it is run, it will star interacting with the tool. Following is a simplified version of an exp script used for install gcloud tool.

spawn ./installer.sh
expect -exact "Installation directory (this will create a google-cloud-sdk subdirectory) (/root): "
send -- "\r"
expect -exact "Do you want to help improve the Google Cloud SDK (y/N)?  "
send -- "N\r"
expect -exact "Do you want to continue (Y/n)?  "
send -- "y\r"
expect -exact "\[/root/.bashrc\]:  "
send -- "\r"
expect eof

To figure out how to write an exp script took a loong time. Then the question was, how can others help contributing with writing tests if writing tests are hard. Then we looked for solutions and found an amazing tool called autoexpect which kinda records real human interactions with a script or tool and generate an exp script for us. However, when first recorded it was recording everything! From download logs to progress bar updates everything was recorded in exp scripts and it was a mess. Then there was a small option where we can only record prompts & user inputs to them. This made the exp scripts generate more clears and simple. We will be using this for generating exp scripts going forward.

As I mentioned in the last post, I tired if I can run tests only for the changed or added installer scripts on Pull Request with GitHub Actions. I tied using git command on this, but seems GitHub Actions are behaving bit different than it works on local machine. My git diff didn’t give me any result when run on Pull Requests. Then I found there is an Git Diff GitHub Action which does exactly what I wanted to do! It gives us a list of changed or added files as an environment variable to the next steps. I can use this to figure our what tests needs to be run again on the Pull Request to verify the changed in the Pull Request has’t break anything. I tired it with a test Pull Request and it worked as expected. You can see it here. Coming week, I will prepare a GitHub Action which will run tests on Ubuntu and Alpine only for the changed installer script using ShellSpec.