2024
Toastify
Migrated the toastify from ‘astro-ve’ to ‘astropad’. We can not migrate DOM scripts to a web worker, so we will have to be careful on how we handle the toast notifcations. There is the option of using the preline toast but some of our older sites still use toastify, thus we want to make sure we have both as an option.
Flowbite
While we are using preline library on kbve, I believe for herbmail we will be using the flowbite library? Thus we need to migrate the flowbite over from astro-ve to astropad! There are a couple smaller things that I wanted to adjust for but this should be a small and easy task for now. For a side note, the rareicon website will be shadui and probably react-three-fiber combined? The idea of a space dock being the core of the game is just way too good for us to just throw to the side.
Readme
Updating the monorepo readme, I will start with fixing up some of the image shields! Added the fudster package and the nodejs packages to the monorepo. The readme should include faster links to the docs and exact locations for the different projects/packages. I suppose we could also move the notes directly into the readme files, then during the build process of kbve.com, we pull the readmes from the dev branch? This way we do not have to write the readme files twice and have a bit of sync between the docs on the website and the markdown files in each nx project.
Go
Let me go ahead and add the go nx bindings to our monorepo, which should work fine because we are on nx 18.
We will create the first package like this go-portside and then build out the go-rareicon from the application side.
This is will be for test casing and the general dirty napkin side of things.
Okay! Doing this before I start driving around like a madman, going to use my phone this time to start the go project.
The goal should be to get this out under the apps folder as go_icon, then we can loop back around to get the official readme up and running.
The integration of supabase-go will be then after we get the base pipeline operational, probably could also deploy it to the helm too, hmm.
DevOps
Updated the devops library and added a new function to help automate the pull requests. For this script, we want to make sure that, ugh, you know what, we will just run with what we got! Let me save the state, I will push back the protobuf update and just begin pushing through the test cases for the patch. Yay! After 8 test cases but it might have been closer 20 but its okay, who is counting?
DanDaDan
Definitely the best anime of 2024, its a perfect blend of ghost stories and durarara! I believe it should be on everyones watch list, gonna hype it out too. Yet I hate having to wait each week for a new episode, but hey, its another thing to fill that kill tony void. Speaking of which, I am super excited for tonights episode of kill tony, I need that laugh.
Github
Looks like the actions are breaking because of a workflow, aka auto-pull, and the reason behind it breaking is that dockerhub is denying a docker image pull.
There are a couple solutions to this problem, we could forward over our dockerhub login to increase the rates, this would be easy and should resolve that problem.
However, I want to be a bit more complicated and maybe we could just remove that action from the workflow and use our devops library to do the automatic pull for us?
Or we could swap out the action to use https://github.com/peter-evans/create-pull-request instead?
The issue that I can see already with our devops library is that it might cause some problems, but hey, we are learning right!