Weekly Telescope Podcast
With the imminence of midterms madness, this week was fairly quiet for most of the students on Telescope. Nevertheless, there has been important work going on in expanding our footsteps in the world of micro-services. We rolled out an impetuous switch the UI 2.0 and cleaned up after porting from Gatsby.
As for myself, I have primarily focused on investigating the changelog generation issue. Since our old changelog generator has not produced any results during the 1.7.0 release, and was well-hated by David for making us follow specific commit message formatting, its fate was clear. Even though I couldn’t fight my curiosity why it was failing, I could not get any clear answers. I have tried to reproduce the bug on my forked repository, and I achieved the same results. We have not changed any configurations or updated the action since our 1.6.0 release, so my best guess is that it probably just didn’t feel comfortable working under the pressure of everyone not in favour of being constrained to certain restrictions in commit messages…Either way, I have followed Chris’s commandments from our last release and scrapped it for good. Especially, when there was a new, more popular and better maintained alternative found, with a way richer configuration options. The action will create the changelog based on the pull requests and assign them to categories you specify in the configuration file based on labels. Here is an extract from the JSON configuration file I defined (kudos to Josue):
{
"categories": [
{
"title": "## 🚀 Autodeployment",
"labels": ["area: autodeployment"]
},
{
"title": "## 🛠 Back-end",
"labels": ["area: back-end"]
},
...As you can see, it is supposed to be fairly simple and you can put markdown in it as well. I am surprised no one’s judged my emoji choices yet! I have tested the new action on my forked repository and it seemed to be working fine. Lets see how it behaves for 1.8.0.
Apart from that, I have also taken time to look into micro-services and David’s introduction to containerization with Docker was very helpful for that. The Seneca’s SSO authentication flow that we have to use is quite a monster. Even though I wasn’t able to dig into every line of what Dave has written, his overview helped a lot to figure out the flow. Reviewing the code was somewhat painful, but reading clean code is a very nice exercise which every should attempt.
Lastly, I have also been monitoring our Dependabot behaviour this week. One downside of our current configuration is that the bot would only create one PR a week for each package file automatically. And it looks like we will most likely have more than one dependency update a week, which can bring us back to a cluttered outdated dependencies list. I think we should keep an eye on it…
