Working on installer.to with SCoRe Lab for GSoC 2020: Week 9
My previous Medium article got published under SCoRe as https://medium.com/scorelab/working-on-installer-to-with-score-lab-for-gsoc-2020-week-8-a09853e1c8d
This week I worked on the final steps of the Continuous Delivery flow! I’m feeling amazing seeing how the whole flow is now working together like a charm.
With the latest changes, when ever a contributor adds a new installer.toml or updates an existing one, my generator script will generate the installer.sh file, generate the minified version of it as installer.min.sh, update the README.md, generates the installers.toml with the summary of the all the installers we have .
Now, with the new Continuous Delivery additions, I am now commiting these newly added files and updated files to git and then creates a PR to GitHub with all the new changes!
It looks like this,
I’m mentioning the relevant PR of in this new PR, to show from which PR this installer.toml got merged to GitHub which made it generate this second PR. Also, I’m adding two GitHub labels and automated-pr and continuous-delivery to show them they are auto generated and related to continuous delivery.
I first went through the GitHub API but it was bit complex, had to call lot of call, to identify the PR these changes are generated from, checking diffs, then committing, creating PR, add many more. Then I started looking for an GitHub action to to this. I found several GitHub Actions but none of them had my full need covered.
Then I combined two GitHub Actions into one workflow to get my full flow done. One GitHub Action looks for the relevant PR the GitHub build was triggered for and reports the PR id. In the other GitHub Action, I’m committing the files I generated and updated and then creating the PR. There I use the PR id found by the previous GitHub Action to link the original PR to this new PR.
Now the full flow is complete! One has to simply write a installer.toml and merge to master via a PR. Then my Continuous Delivery method will kick in and generated installer.sh, minifies it and generates installer.min.sh, updated the README.md with the latest information on installer support, and update the installers.toml, commits them and create a PR with linking to the previous PR. Then the maintainers only has to merge this new PR which has all these new files and updates generated.
