Fourth Week [June 10th- June 16th] [2nd PSF Weekly Check-in]
1. We finalized the pipeline using azure services for making the documentation of the build and deploying it to gh-pages. We successfully installed the ssh key to give us access. to deploy to gh-pages. I learned more about how sphinx and how it makes the documentation. I also optimized the code, deleting everything we do not need from both the azure-pipline script, and the additional called on shell file that runs the script to make the sphinx documentation and push it to gh-pages.
View Blog Post
2. I am working on the official documentation input for continious intergration using azure services, by editing the sphinx files. I am also formally learning and implementing markdown language. https://markdown-guide.readthedocs.io/. After that, I would like to implement better methods of creating our environment before making the build on the virtual machine host. As we spend about 4.5 minutes each time installing the environment using conda.
3. I actually resolved my problem from last week, of a file merger conflict, by understanding more about what sphinx does, and identifying the necessary files to make the documentation from the files that are created as a result of making it. We currently make the build in a directory then move them all to another empty directory.
It was difficult to comprehend how the documented files are made via rst files, but by consistantly looking at the current documentation of our organization (Tardis) and the written files, and looking at tutorials, I feel quite comfortable in making them.
Third Week [June 3rd - June 9th] [1st PSF Blog]
View Blog Post
This week, we are on the verge of finishing the intended task of moving from travis-ci to azure pipelines for continiously integrating the code of our repository [Tardis]. I was able to successuly install a ssh-key, which is used as a deploy key for deployment to github. The format of this was different from that used from travis-ci. The Azure library stores and encrypts the key files, which is then decrypted whenever the pipeline runs. There were three obstacles. The main obstacle was the steps suggested by the azure website to install the key was not detailed enough, as it requested three inputs [public key, private key, and know hosts], but did not specify what input format. The error I was getting was specific to the public key, but giving me somewhat of a vague error with little google solutions [Cannot get the base64 portion of the public key], I was able to figure this out from the azure repository on github, and traced it back to the main code file, in which it was clear that the input is a string. https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/InstallSSHKeyV0/installsshkey-util.ts, and I was then able to identify the correct input of the knownhost also. Another mainly due to changing from the main tardis repository to my forked repository. During the process documenting the build, it retrieves files from another repository [in reference to the main one] which is referenced based on an enviromental variable of the name of the main tardis repo. Since I also changed the environmental variable to the name of my forked repository[Youssef15015/tardis] of the main tardis repository[tardis-sn/tardis], the files were not retrieved from the second primary repository[tardis-sn/tardis-refdata]. I simply forked the second repository being used, so the naming reference was solved [Youssef15015/tardis-refdata]. This will not be an issue when I merge to the main branch, but it was good to make sure everything works. I could have also changed the environmental variable. Another issue that is still unsolved, is with making the html documentation itself using sphinx rather than doctr (which is only intended for travis). Eventhough there is a line to empty the documentation from last time every time it runs for the new documentation to be stored, the second time I run the code some parts fail to be written due to conflict of already existing content. I am unsure at the moment why this is a problem, but I do not suspect it to be an issue for long. I also documented what I did in the pipeline yaml fille [The file that is used to communicate to Azure-services] (generating the key, downloading the file the ssh-key from the azure library, format of each file for the ssh key, and then leading them to the file that is used to build and deploy. I also helped another summer coder make this entire setup for himself, and must catch up to fix my third error and make a final pull request to merge to the main repository. The next steps would be to completely optimize the script to the minimum, making sure that doctr cannot be used for azure-services, and then exploring all the wonderful and many additional services offered by azure.
Second Week [May 27th - June 2nd]
View Blog Post
1. This week I have setting up and understanding the continous integration done by the services of travis ci. The main thing I learned is how to set an encrypted environment variable to access a deploy key that is intended to deploy the documentation of our git repo build. The deploy key is generated through github, and serves as an access point to deploy to one of the repository's branches.
2. I am now testing deploying files from my computer without doctr, to eventually use it for azure. Doctr, more or less, encrypts a ssh key that was set up as a deploy key, unlocks it for a specific branch, then deploys the documentation build that is available.
3.The main issue came up when I attempted to deploy docs from my local computer using the same software it uses "doctr", which is only intended for travis ci. Another issure, is the passphrase I set for unlocking the potentially encrypted deploy key file, which cannot have special characters such as '+' and '='
GSoC 2019 Summer Blog
View Blog Post
1. This week I have been working on a yaml file that uses continious integration to build the documentation of the git repository of tardis.
2. The goal is to shift the continous integration from Travis CI to Azure pipelines, and to deploy the documentation either using doctr like in tardis or a different method.
3. It is sometimes difficult for me to envision the virtual environment setup to build the github repository, whether all the variables and resources are properly defined.